kernel/linux.git/drivers/video/fbdev/efifb.c, branch linux-4.20.y

efifb: BGRT: Add nobgrt option

2018-09-26T16:11:22+00:00

In some setups restoring the BGRT logo is undesirable, allow passing video=efifb:nobgrt on the kernel commandline to disable it. Reported-by: David Herrmann Signed-off-by: Hans de Goede Reviewed-by: David Herrmann Signed-off-by: Bartlomiej Zolnierkiewicz

Merge tag 'fbdev-v4.19' of https://github.com/bzolnier/linux

2018-08-23T22:44:58+00:00

Pull fbdev updates from Bartlomiej Zolnierkiewicz: "Mostly small fixes and cleanups for fb drivers (the biggest updates are for udlfb and pxafb drivers). This also adds deferred console takeover support to the console code and efifb driver. Summary: - add support for deferred console takeover, when enabled defers fbcon taking over the console from the dummy console until the first text is displayed on the console - together with the "quiet" kernel commandline option this allows fbcon to still be used together with a smooth graphical bootup (Hans de Goede) - improve console locking debugging code (Thomas Zimmermann) - copy the ACPI BGRT boot graphics to the framebuffer when deferred console takeover support is used in efifb driver (Hans de Goede) - update udlfb driver - fix lost console when the user unplugs a USB adapter, fix the screen corruption issue, fix locking and add some performance optimizations (Mikulas Patocka) - update pxafb driver - fix using uninitialized memory, switch to devm_* API, handle initialization errors and add support for lcd-supply regulator (Daniel Mack) - add support for boards booted with a DeviceTree in pxa3xx_gcu driver (Daniel Mack) - rename omap2 module to omap2fb.ko to avoid conflicts with omap1 driver (Arnd Bergmann) - enable ACPI-based enumeration for goldfishfb driver (Yu Ning) - fix goldfishfb driver to make user space Android code use 60 fps (Christoffer Dall) - print big fat warning when nomodeset kernel parameter is used in vgacon driver (Lyude Paul) - remove VLA usage from fsl-diu-fb driver (Kees Cook) - misc fixes (Julia Lawall, Geert Uytterhoeven, Fredrik Noring, Yisheng Xie, Dan Carpenter, Daniel Vetter, Anton Vasilyev, Randy Dunlap, Gustavo A. R. Silva, Colin Ian King, Fengguang Wu) - misc cleanups (Roman Kiryanov, Yisheng Xie, Colin Ian King)" * tag 'fbdev-v4.19' of https://github.com/bzolnier/linux: (54 commits) Documentation/fb: corrections for fbcon.txt fbcon: Do not takeover the console from atomic context dummycon: Stop exporting dummycon_[un]register_output_notifier fbcon: Only defer console takeover if the current console driver is the dummycon fbcon: Only allow FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER if fbdev is builtin fbdev: omap2: omapfb: fix ifnullfree.cocci warnings fbdev: omap2: omapfb: fix bugon.cocci warnings fbdev: omap2: omapfb: fix boolreturn.cocci warnings fb: amifb: fix build warnings when not builtin fbdev/core: Disable console-lock warnings when fb.lockless_register_fb is set console: Replace #if 0 with atomic var 'ignore_console_lock_warning' udlfb: use spin_lock_irq instead of spin_lock_irqsave udlfb: avoid prefetch udlfb: optimization - test the backing buffer udlfb: allow reallocating the framebuffer udlfb: set line_length in dlfb_ops_set_par udlfb: handle allocation failure udlfb: set optimal write delay udlfb: make a local copy of fb_ops udlfb: don't switch if we are switching to the same videomode ...

efifb: BGRT: Do not copy the boot graphics for non native resolutions

2018-07-24T17:11:28+00:00

On x86 some firmwares use a low non native resolution for the display when they have shown some text messages. While keeping the bgrt filled with info for the native resolution. If the bgrt image intended for the native resolution still fits, it will be displayed very close to the right edge of the display looking quite bad. This commits adds a (heuristics based) checks for this and makes efifb not show the boot graphics when this is the case. Signed-off-by: Hans de Goede Signed-off-by: Bartlomiej Zolnierkiewicz

fbdev/efifb: Honour UEFI memory map attributes when mapping the FB

2018-07-15T22:43:12+00:00

If the framebuffer address provided by the Graphics Output Protocol (GOP) is covered by the UEFI memory map, it will tell us which memory attributes are permitted when mapping this region. In some cases, (KVM guest on ARM), violating this will result in loss of coherency, which means that updates sent to the framebuffer by the guest will not be observeable by the host, and the emulated display simply does not work. So if the memory map contains such a description, take the attributes field into account, and add support for creating WT or WB mappings of the framebuffer region. Tested-by: Laszlo Ersek Signed-off-by: Ard Biesheuvel Acked-by: Bartlomiej Zolnierkiewicz Cc: Linus Torvalds Cc: Peter Jones Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180711094040.12506-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

efifb: Copy the ACPI BGRT boot graphics to the framebuffer

2018-07-03T15:43:10+00:00

On systems where fbcon is configured for deferred console takeover, the intend is for the framebuffer to show the boot graphics (e.g a vendor logo) until some message (e.g. an error) is printed or a graphical session takes over. Some firmware relies on the OS to show the boot graphics. This patch adds support to efifb to show the boot graphics and automatically enables this when fbcon is configured for deferred console takeover. Signed-off-by: Hans de Goede Signed-off-by: Bartlomiej Zolnierkiewicz

efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk

2017-12-04T22:03:21+00:00

On some hardware the LCD panel is not mounted upright in the casing, but rotated by 90 degrees. In this case we want the console to automatically be rotated to compensate. The drm subsys has a quirk table for this, use the drm_get_panel_orientation_quirk function to get the panel orientation and set info->fbcon_rotate_hint based on this, so that the fbcon console on top of efifb gets automatically rotated to compensate for the panel orientation. Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-7-hdegoede@redhat.com

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

2017-11-02T10:10:55+00:00

Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it

2017-08-21T07:43:50+00:00

On UEFI systems, the firmware may expose a Graphics Output Protocol (GOP) instance to which the efifb driver attempts to attach in order to provide a minimal, unaccelerated framebuffer. The GOP protocol itself is not very sophisticated, and only describes the offset and size of the framebuffer in memory, and the pixel format. If the GOP framebuffer is provided by a PCI device, it will have been configured and enabled by the UEFI firmware, and the GOP protocol will simply point into a live BAR region. However, the GOP protocol itself does not describe this relation, and so we have to take care not to reconfigure the BAR without taking efifb's dependency on it into account. Commit: 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that covers the framebuffer") attempted to do so by claiming the BAR resource early on, which prevents the PCI resource allocation routines from changing it. However, it turns out that this only works if the PCI device is not behind any bridges, since the bridge resources need to be claimed first. So instead, allow the BAR to be moved, but make the efifb driver deal with that gracefully. So record the resource that covers the BAR early on, and if it turns out to have moved by the time we probe the efifb driver, update the framebuffer address accordingly. While this is less likely to occur on x86, given that the firmware's PCI resource allocation is more likely to be preserved, this is a worthwhile sanity check to have in place, and so let's remove the preprocessor conditional that makes it !X86 only. Signed-off-by: Ard Biesheuvel Reviewed-by: Peter Jones Acked-by: Bartlomiej Zolnierkiewicz Acked-by: Bjorn Helgaas Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170818194947.19347-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

efifb: allow user to disable write combined mapping.

2017-07-31T16:45:41+00:00

This patch allows the user to disable write combined mapping of the efifb framebuffer console using an nowc option. A customer noticed major slowdowns while logging to the console with write combining enabled, on other tasks running on the same CPU. (10x or greater slow down on all other cores on the same CPU as is doing the logging). I reproduced this on a machine with dual CPUs. Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz (6 core) I wrote a test that just mmaps the pci bar and writes to it in a loop, while this was running in the background one a single core with (taskset -c 1), building a kernel up to init/version.o (taskset -c 8) went from 13s to 133s or so. I've yet to explain why this occurs or what is going wrong I haven't managed to find a perf command that in any way gives insight into this. 11,885,070,715 instructions # 1.39 insns per cycle vs 12,082,592,342 instructions # 0.13 insns per cycle is the only thing I've spotted of interest, I've tried at least: dTLB-stores,dTLB-store-misses,L1-dcache-stores,LLC-store,LLC-store-misses,LLC-load-misses,LLC-loads,\mem-loads,mem-stores,iTLB-loads,iTLB-load-misses,cache-references,cache-misses For now it seems at least a good idea to allow a user to disable write combining if they see this until we can figure it out. Note also most users get a real framebuffer driver loaded when kms kicks in, it just happens on these machines the kernel didn't support the gpu specific driver. Signed-off-by: Dave Airlie Acked-by: Peter Jones Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Linus Torvalds Signed-off-by: Bartlomiej Zolnierkiewicz

efi/fb: Correct PCI_STD_RESOURCE_END usage

2017-06-13T16:44:23+00:00

PCI_STD_RESOURCE_END is (confusingly) the index of the last valid BAR, not the *number* of BARs. To iterate through all possible BARs, we need to include PCI_STD_RESOURCE_END. Fixes: 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that covers the framebuffer") Signed-off-by: Bjorn Helgaas