linux-stable.git/drivers/video/fbdev/efifb.c, branch linux-4.9.y

efi/fb: Correct PCI_STD_RESOURCE_END usage

2018-11-10T15:42:45+00:00

[ Upstream commit 92a16c86299c64f58f320e491977408ba31b8c3c ]

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 
Signed-off-by: Sasha Levin

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

2017-04-21T07:31:20+00:00

commit 55d728a40d368ba80443be85c02e641fc9082a3f upstream.

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: 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 
Signed-off-by: Greg Kroah-Hartman

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

video: fbdev: drop owner assignment from platform_drivers

2014-10-20T14:21:51+00:00

A platform_driver does not need to set an owner, it will be populated by the
driver core.

Signed-off-by: Wolfram Sang

x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

2014-07-10T22:48:48+00:00

Commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)") added
efifb vga_default_device() so EFI systems that do not load shadow VBIOS or
setup VGA get proper value for boot_vga PCI sysfs attribute on the
corresponding PCI device.

Xorg doesn't detect devices when boot_vga=0, e.g., on some EFI systems such
as MacBookAir2,1.  Xorg detects the GPU and finds the DRI device but then
bails out with "no devices detected".

Note: When vga_default_device() is set boot_vga PCI sysfs attribute
reflects its state.  When unset this attribute is 1 whenever
IORESOURCE_ROM_SHADOW flag is set.

With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete
while having native drivers for the GPU also makes selecting sysfb/efifb
optional.

Remove the efifb implementation of vga_default_device() and initialize
vgaarb's vga_default_device() with the PCI GPU that matches boot
screen_info in pci_fixup_video().

[bhelgaas: remove unused "dev" in efifb_setup()]
Fixes: b4aa0163056b ("efifb: Implement vga_default_device() (v2)")
Tested-by: Anibal Francisco Martinez Cortina 
Signed-off-by: Bruno Prémont 
Signed-off-by: Bjorn Helgaas 
Acked-by: Matthew Garrett 
CC: stable@vger.kernel.org	# v3.5+