linux.git/drivers/video/fbdev/efifb.c, branch v4.13

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

efi/fb: Avoid reconfiguration of BAR that covers the framebuffer

2017-04-05T10:25:53+00:00

On UEFI systems, the PCI subsystem is enumerated by the firmware,
and if a graphical framebuffer is exposed via a PCI device, its base
address and size are exposed to the OS via the Graphics Output
Protocol (GOP).

On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
scratch at boot. This may result in the GOP framebuffer address to
become stale, if the BAR covering the framebuffer is modified. This
will cause the framebuffer to become unresponsive, and may in some
cases result in unpredictable behavior if the range is reassigned to
another device.

So add a non-x86 quirk to the EFI fb driver to find the BAR associated
with the GOP base address, and claim the BAR resource so that the PCI
core will not move it.

Signed-off-by: Ard Biesheuvel 
Cc:  # v4.7+
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Jones 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: leif.lindholm@linaro.org
Cc: linux-efi@vger.kernel.org
Cc: lorenzo.pieralisi@arm.com
Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...")
Link: http://lkml.kernel.org/r/20170404152744.26687-3-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar

efifb: Show framebuffer layout as device attributes

2016-10-18T15:11:19+00:00

Userland sometimes needs to know what the framebuffer configuration was
when the firmware was running. This enables us to render localized
status strings during firmware updates using the data from the ACPI BGRT
table and the protocol described at the url below:

  https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/boot-screen-components

This patch also fixes up efifb's printk() usage to use pr_warn() /
pr_info() / pr_err() instead.

Tested-by: Ard Biesheuvel 
Signed-off-by: Peter Jones 
Signed-off-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20161018143318.15673-8-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar

fbdev/efifb: Fix 16 color palette entry calculation

2016-08-11T14:54:56+00:00

When using efifb with a 16-bit (5:6:5) visual, fbcon's text is rendered
in the wrong colors - e.g. text gray (#aaaaaa) is rendered as green
(#50bc50) and neighboring pixels have slightly different values
(such as #50bc78).

The reason is that fbcon loads its 16 color palette through
efifb_setcolreg(), which in turn calculates a 32-bit value to write
into memory for each palette index.
Until now, this code could only handle 8-bit visuals and didn't mask
overlapping values when ORing them.

With this patch, fbcon displays the correct colors when a qemu VM is
booted in 16-bit mode (in GRUB: "set gfxpayload=800x600x16").

Fixes: 7c83172b98e5 ("x86_64 EFI boot support: EFI frame buffer driver")  # v2.6.24+
Signed-off-by: Max Staudt 
Acked-By: Peter Jones 
Cc: stable@vger.kernel.org
Signed-off-by: Tomi Valkeinen

Merge tag 'fbdev-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux

2016-05-20T18:01:02+00:00

Pull fbdev updates from Tomi Valkeinen:

 - imxfb: fix lcd power up

 - small fixes and cleanups

* tag 'fbdev-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
  fbdev: Use IS_ENABLED() instead of checking for built-in or module
  efifb: Don't show the mapping VA
  video: AMBA CLCD: Remove unncessary include in amba-clcd.c
  fbdev: ssd1307fb: Fix charge pump setting
  Documentation: fb: fix spelling mistakes
  fbdev: fbmem: implement error handling in fbmem_init()
  fbdev: sh_mipi_dsi: remove driver
  video: fbdev: imxfb: add some error handling
  video: fbdev: imxfb: fix semantic of .get_power and .set_power
  video: fbdev: omap2: Remove deprecated regulator_can_change_voltage() usage

efifb: Don't show the mapping VA

2016-05-13T11:42:39+00:00

The framebuffer mapping virtual address leaks information about the
kernel memory layout.  Stop logging it.

Cc: Peter Jones 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andy Lutomirski 
Signed-off-by: Peter Jones 
Signed-off-by: Tomi Valkeinen

efifb: Use builtin_platform_driver and drop unused includes

2016-04-28T09:33:58+00:00

Since efifb can only be built directly into the kernel, drop the module
specific includes and definitions. Drop some other includes we don't need
as well.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Matt Fleming 
Acked-by: Peter Jones 
Cc: Borislav Petkov 
Cc: David Herrmann 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1461614832-17633-20-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar

x86/efi/efifb: Move DMI based quirks handling out of generic code

2016-04-28T09:33:57+00:00

The efifb quirks handling based on DMI identification of the platform is
specific to x86, so move it to x86 arch code.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Matt Fleming 
Acked-by: David Herrmann 
Acked-by: Peter Jones 
Cc: Borislav Petkov 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1461614832-17633-19-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar

efifb: Add support for 64-bit frame buffer addresses

2015-10-12T13:20:06+00:00

The EFI Graphics Output Protocol uses 64-bit frame buffer addresses
but these get truncated to 32-bit by the EFI boot stub when storing
the address in the 'lfb_base' field of 'struct screen_info'.

Add a 'ext_lfb_base' field for the upper 32-bits of the frame buffer
address and set VIDEO_TYPE_CAPABILITY_64BIT_BASE when the field is
useable.

It turns out that the reason no one has required this support so far
is that there's actually code in tianocore to "downgrade" PCI
resources that have option ROMs and 64-bit BARS from 64-bit to 32-bit
to cope with legacy option ROMs that can't handle 64-bit addresses.
The upshot is that basically all GOP devices in the wild use a 32-bit
frame buffer address.

Still, it is possible to build firmware that uses a full 64-bit GOP
frame buffer address. Chad did, which led to him reporting this issue.

Add support in anticipation of GOP devices using 64-bit addresses more
widely, and so that efifb works out of the box when that happens.

Reported-by: Chad Page 
Cc: Pete Hawkins 
Acked-by: Peter Jones 
Cc: Matthew Garrett 
Cc: Geert Uytterhoeven 
Signed-off-by: Matt Fleming