OpenCloudOS-Kernel/drivers/video/fbdev/efifb.c

672 lines
18 KiB
C
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license 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 <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 22:07:57 +08:00
// SPDX-License-Identifier: GPL-2.0
/*
* Framebuffer driver for EFI/UEFI based system
*
* (c) 2006 Edgar Hucek <gimli@dark-green.com>
* Original efi driver written by Gerd Knorr <kraxel@goldbach.in-berlin.de>
*
*/
#include <linux/kernel.h>
#include <linux/efi.h>
#include <linux/efi-bgrt.h>
#include <linux/errno.h>
#include <linux/fb.h>
#include <linux/pci.h>
#include <linux/platform_device.h>
#include <linux/printk.h>
#include <linux/screen_info.h>
#include <video/vga.h>
#include <asm/efi.h>
#include <drm/drm_utils.h> /* For drm_get_panel_orientation_quirk */
#include <drm/drm_connector.h> /* For DRM_MODE_PANEL_ORIENTATION_* */
struct bmp_file_header {
u16 id;
u32 file_size;
u32 reserved;
u32 bitmap_offset;
} __packed;
struct bmp_dib_header {
u32 dib_header_size;
s32 width;
s32 height;
u16 planes;
u16 bpp;
u32 compression;
u32 bitmap_size;
u32 horz_resolution;
u32 vert_resolution;
u32 colors_used;
u32 colors_important;
} __packed;
static bool use_bgrt = true;
static bool request_mem_succeeded = false;
static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
static struct fb_var_screeninfo efifb_defined = {
.activate = FB_ACTIVATE_NOW,
.height = -1,
.width = -1,
.right_margin = 32,
.upper_margin = 16,
.lower_margin = 4,
.vsync_len = 4,
.vmode = FB_VMODE_NONINTERLACED,
};
static struct fb_fix_screeninfo efifb_fix = {
.id = "EFI VGA",
.type = FB_TYPE_PACKED_PIXELS,
.accel = FB_ACCEL_NONE,
.visual = FB_VISUAL_TRUECOLOR,
};
static int efifb_setcolreg(unsigned regno, unsigned red, unsigned green,
unsigned blue, unsigned transp,
struct fb_info *info)
{
/*
* Set a single color register. The values supplied are
* already rounded down to the hardware's capabilities
* (according to the entries in the `var' structure). Return
* != 0 for invalid regno.
*/
if (regno >= info->cmap.len)
return 1;
if (regno < 16) {
red >>= 16 - info->var.red.length;
green >>= 16 - info->var.green.length;
blue >>= 16 - info->var.blue.length;
((u32 *)(info->pseudo_palette))[regno] =
(red << info->var.red.offset) |
(green << info->var.green.offset) |
(blue << info->var.blue.offset);
}
return 0;
}
/*
* If fbcon deffered console takeover is configured, the intent is for the
* framebuffer to show the boot graphics (e.g. vendor logo) until there is some
* (error) message to display. But the boot graphics may have been destroyed by
* e.g. option ROM output, detect this and restore the boot graphics.
*/
#if defined CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER && \
defined CONFIG_ACPI_BGRT
static void efifb_copy_bmp(u8 *src, u32 *dst, int width, struct screen_info *si)
{
u8 r, g, b;
while (width--) {
b = *src++;
g = *src++;
r = *src++;
*dst++ = (r << si->red_pos) |
(g << si->green_pos) |
(b << si->blue_pos);
}
}
#ifdef CONFIG_X86
/*
* 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 function checks for this.
*/
static bool efifb_bgrt_sanity_check(struct screen_info *si, u32 bmp_width)
{
/*
* All x86 firmwares horizontally center the image (the yoffset
* calculations differ between boards, but xoffset is predictable).
*/
u32 expected_xoffset = (si->lfb_width - bmp_width) / 2;
return bgrt_tab.image_offset_x == expected_xoffset;
}
#else
static bool efifb_bgrt_sanity_check(struct screen_info *si, u32 bmp_width)
{
return true;
}
#endif
static void efifb_show_boot_graphics(struct fb_info *info)
{
u32 bmp_width, bmp_height, bmp_pitch, screen_pitch, dst_x, y, src_y;
struct screen_info *si = &screen_info;
struct bmp_file_header *file_header;
struct bmp_dib_header *dib_header;
void *bgrt_image = NULL;
u8 *dst = info->screen_base;
if (!use_bgrt)
return;
if (!bgrt_tab.image_address) {
pr_info("efifb: No BGRT, not showing boot graphics\n");
return;
}
if (bgrt_tab.status & 0x06) {
pr_info("efifb: BGRT rotation bits set, not showing boot graphics\n");
return;
}
/* Avoid flashing the logo if we're going to print std probe messages */
if (console_loglevel > CONSOLE_LOGLEVEL_QUIET)
return;
/* bgrt_tab.status is unreliable, so we don't check it */
if (si->lfb_depth != 32) {
pr_info("efifb: not 32 bits, not showing boot graphics\n");
return;
}
bgrt_image = memremap(bgrt_tab.image_address, bgrt_image_size,
MEMREMAP_WB);
if (!bgrt_image) {
pr_warn("efifb: Ignoring BGRT: failed to map image memory\n");
return;
}
if (bgrt_image_size < (sizeof(*file_header) + sizeof(*dib_header)))
goto error;
file_header = bgrt_image;
if (file_header->id != 0x4d42 || file_header->reserved != 0)
goto error;
dib_header = bgrt_image + sizeof(*file_header);
if (dib_header->dib_header_size != 40 || dib_header->width < 0 ||
dib_header->planes != 1 || dib_header->bpp != 24 ||
dib_header->compression != 0)
goto error;
bmp_width = dib_header->width;
bmp_height = abs(dib_header->height);
bmp_pitch = round_up(3 * bmp_width, 4);
screen_pitch = si->lfb_linelength;
if ((file_header->bitmap_offset + bmp_pitch * bmp_height) >
bgrt_image_size)
goto error;
if ((bgrt_tab.image_offset_x + bmp_width) > si->lfb_width ||
(bgrt_tab.image_offset_y + bmp_height) > si->lfb_height)
goto error;
if (!efifb_bgrt_sanity_check(si, bmp_width))
goto error;
pr_info("efifb: showing boot graphics\n");
for (y = 0; y < si->lfb_height; y++, dst += si->lfb_linelength) {
/* Only background? */
if (y < bgrt_tab.image_offset_y ||
y >= (bgrt_tab.image_offset_y + bmp_height)) {
memset(dst, 0, 4 * si->lfb_width);
continue;
}
src_y = y - bgrt_tab.image_offset_y;
/* Positive header height means upside down row order */
if (dib_header->height > 0)
src_y = (bmp_height - 1) - src_y;
memset(dst, 0, bgrt_tab.image_offset_x * 4);
dst_x = bgrt_tab.image_offset_x;
efifb_copy_bmp(bgrt_image + file_header->bitmap_offset +
src_y * bmp_pitch,
(u32 *)dst + dst_x, bmp_width, si);
dst_x += bmp_width;
memset((u32 *)dst + dst_x, 0, (si->lfb_width - dst_x) * 4);
}
memunmap(bgrt_image);
return;
error:
memunmap(bgrt_image);
pr_warn("efifb: Ignoring BGRT: unexpected or invalid BMP data\n");
}
#else
static inline void efifb_show_boot_graphics(struct fb_info *info) {}
#endif
static void efifb_destroy(struct fb_info *info)
{
if (info->screen_base) {
if (mem_flags & (EFI_MEMORY_UC | EFI_MEMORY_WC))
iounmap(info->screen_base);
else
memunmap(info->screen_base);
}
if (request_mem_succeeded)
release_mem_region(info->apertures->ranges[0].base,
info->apertures->ranges[0].size);
fb_dealloc_cmap(&info->cmap);
}
static const struct fb_ops efifb_ops = {
.owner = THIS_MODULE,
.fb_destroy = efifb_destroy,
.fb_setcolreg = efifb_setcolreg,
.fb_fillrect = cfb_fillrect,
.fb_copyarea = cfb_copyarea,
.fb_imageblit = cfb_imageblit,
};
static int efifb_setup(char *options)
{
char *this_opt;
if (options && *options) {
while ((this_opt = strsep(&options, ",")) != NULL) {
if (!*this_opt) continue;
efifb_setup_from_dmi(&screen_info, this_opt);
if (!strncmp(this_opt, "base:", 5))
screen_info.lfb_base = simple_strtoul(this_opt+5, NULL, 0);
else if (!strncmp(this_opt, "stride:", 7))
screen_info.lfb_linelength = simple_strtoul(this_opt+7, NULL, 0) * 4;
else if (!strncmp(this_opt, "height:", 7))
screen_info.lfb_height = simple_strtoul(this_opt+7, NULL, 0);
else if (!strncmp(this_opt, "width:", 6))
screen_info.lfb_width = simple_strtoul(this_opt+6, NULL, 0);
efifb: allow user to disable write combined mapping. 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 <airlied@redhat.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-08-01 00:45:41 +08:00
else if (!strcmp(this_opt, "nowc"))
mem_flags &= ~EFI_MEMORY_WC;
else if (!strcmp(this_opt, "nobgrt"))
use_bgrt = false;
}
}
return 0;
}
static inline bool fb_base_is_valid(void)
{
if (screen_info.lfb_base)
return true;
if (!(screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE))
return false;
if (screen_info.ext_lfb_base)
return true;
return false;
}
#define efifb_attr_decl(name, fmt) \
static ssize_t name##_show(struct device *dev, \
struct device_attribute *attr, \
char *buf) \
{ \
return sprintf(buf, fmt "\n", (screen_info.lfb_##name)); \
} \
static DEVICE_ATTR_RO(name)
efifb_attr_decl(base, "0x%x");
efifb_attr_decl(linelength, "%u");
efifb_attr_decl(height, "%u");
efifb_attr_decl(width, "%u");
efifb_attr_decl(depth, "%u");
static struct attribute *efifb_attrs[] = {
&dev_attr_base.attr,
&dev_attr_linelength.attr,
&dev_attr_width.attr,
&dev_attr_height.attr,
&dev_attr_depth.attr,
NULL
};
ATTRIBUTE_GROUPS(efifb);
static bool pci_dev_disabled; /* FB base matches BAR of a disabled device */
drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it 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 <ard.biesheuvel@linaro.org> Reviewed-by: Peter Jones <pjones@redhat.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170818194947.19347-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-08-19 03:49:40 +08:00
static struct pci_dev *efifb_pci_dev; /* dev with BAR covering the efifb */
static struct resource *bar_resource;
static u64 bar_offset;
static int efifb_probe(struct platform_device *dev)
{
struct fb_info *info;
int err, orientation;
unsigned int size_vmode;
unsigned int size_remap;
unsigned int size_total;
char *option = NULL;
efi_memory_desc_t md;
if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
return -ENODEV;
if (fb_get_options("efifb", &option))
return -ENODEV;
efifb_setup(option);
/* We don't get linelength from UGA Draw Protocol, only from
* EFI Graphics Protocol. So if it's not in DMI, and it's not
* passed in from the user, we really can't use the framebuffer.
*/
if (!screen_info.lfb_linelength)
return -ENODEV;
if (!screen_info.lfb_depth)
screen_info.lfb_depth = 32;
if (!screen_info.pages)
screen_info.pages = 1;
if (!fb_base_is_valid()) {
printk(KERN_DEBUG "efifb: invalid framebuffer address\n");
return -ENODEV;
}
printk(KERN_INFO "efifb: probing for efifb\n");
/* just assume they're all unset if any are */
if (!screen_info.blue_size) {
screen_info.blue_size = 8;
screen_info.blue_pos = 0;
screen_info.green_size = 8;
screen_info.green_pos = 8;
screen_info.red_size = 8;
screen_info.red_pos = 16;
screen_info.rsvd_size = 8;
screen_info.rsvd_pos = 24;
}
efifb_fix.smem_start = screen_info.lfb_base;
if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE) {
u64 ext_lfb_base;
ext_lfb_base = (u64)(unsigned long)screen_info.ext_lfb_base << 32;
efifb_fix.smem_start |= ext_lfb_base;
}
drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it 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 <ard.biesheuvel@linaro.org> Reviewed-by: Peter Jones <pjones@redhat.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170818194947.19347-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-08-19 03:49:40 +08:00
if (bar_resource &&
bar_resource->start + bar_offset != efifb_fix.smem_start) {
dev_info(&efifb_pci_dev->dev,
"BAR has moved, updating efifb address\n");
efifb_fix.smem_start = bar_resource->start + bar_offset;
}
efifb_defined.bits_per_pixel = screen_info.lfb_depth;
efifb_defined.xres = screen_info.lfb_width;
efifb_defined.yres = screen_info.lfb_height;
efifb_fix.line_length = screen_info.lfb_linelength;
/* size_vmode -- that is the amount of memory needed for the
* used video mode, i.e. the minimum amount of
* memory we need. */
size_vmode = efifb_defined.yres * efifb_fix.line_length;
/* size_total -- all video memory we have. Used for
* entries, ressource allocation and bounds
* checking. */
size_total = screen_info.lfb_size;
if (size_total < size_vmode)
size_total = size_vmode;
/* size_remap -- the amount of video memory we are going to
* use for efifb. With modern cards it is no
* option to simply use size_total as that
* wastes plenty of kernel address space. */
size_remap = size_vmode * 2;
if (size_remap > size_total)
size_remap = size_total;
if (size_remap % PAGE_SIZE)
size_remap += PAGE_SIZE - (size_remap % PAGE_SIZE);
efifb_fix.smem_len = size_remap;
if (request_mem_region(efifb_fix.smem_start, size_remap, "efifb")) {
request_mem_succeeded = true;
} else {
/* We cannot make this fatal. Sometimes this comes from magic
spaces our resource handlers simply don't know about */
pr_warn("efifb: cannot reserve video memory at 0x%lx\n",
efifb_fix.smem_start);
}
info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev);
if (!info) {
err = -ENOMEM;
goto err_release_mem;
}
platform_set_drvdata(dev, info);
info->pseudo_palette = info->par;
info->par = NULL;
info->apertures = alloc_apertures(1);
if (!info->apertures) {
err = -ENOMEM;
goto err_release_fb;
}
info->apertures->ranges[0].base = efifb_fix.smem_start;
info->apertures->ranges[0].size = size_remap;
if (efi_enabled(EFI_MEMMAP) &&
!efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
if ((efifb_fix.smem_start + efifb_fix.smem_len) >
(md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) {
pr_err("efifb: video memory @ 0x%lx spans multiple EFI memory regions\n",
efifb_fix.smem_start);
err = -EIO;
goto err_release_fb;
}
/*
* If the UEFI memory map covers the efifb region, we may only
* remap it using the attributes the memory map prescribes.
*/
fbdev/efifb: Ignore framebuffer memmap entries that lack any memory types The following commit: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB") updated the EFI framebuffer code to use memory mappings for the linear framebuffer that are permitted by the memory attributes described by the EFI memory map for the particular region, if the framebuffer happens to be covered by the EFI memory map (which is typically only the case for framebuffers in shared memory). This is required since non-x86 systems may require cacheable attributes for memory mappings that are shared with other masters (such as GPUs), and this information cannot be described by the Graphics Output Protocol (GOP) EFI protocol itself, and so we rely on the EFI memory map for this. As reported by James, this breaks some x86 systems: [ 1.173368] efifb: probing for efifb [ 1.173386] efifb: abort, cannot remap video memory 0x1d5000 @ 0xcf800000 [ 1.173395] Trying to free nonexistent resource <00000000cf800000-00000000cf9d4bff> [ 1.173413] efi-framebuffer: probe of efi-framebuffer.0 failed with error -5 The problem turns out to be that the memory map entry that describes the framebuffer has no memory attributes listed at all, and so we end up with a mem_flags value of 0x0. So work around this by ensuring that the memory map entry's attribute field has a sane value before using it to mask the set of usable attributes. Reported-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: <stable@vger.kernel.org> # v4.19+ Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when ...") Link: http://lkml.kernel.org/r/20190516213159.3530-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-05-17 05:31:59 +08:00
md.attribute &= EFI_MEMORY_UC | EFI_MEMORY_WC |
EFI_MEMORY_WT | EFI_MEMORY_WB;
if (md.attribute) {
mem_flags |= EFI_MEMORY_WT | EFI_MEMORY_WB;
mem_flags &= md.attribute;
}
}
if (mem_flags & EFI_MEMORY_WC)
info->screen_base = ioremap_wc(efifb_fix.smem_start,
efifb_fix.smem_len);
else if (mem_flags & EFI_MEMORY_UC)
info->screen_base = ioremap(efifb_fix.smem_start,
efifb_fix.smem_len);
else if (mem_flags & EFI_MEMORY_WT)
info->screen_base = memremap(efifb_fix.smem_start,
efifb_fix.smem_len, MEMREMAP_WT);
else if (mem_flags & EFI_MEMORY_WB)
info->screen_base = memremap(efifb_fix.smem_start,
efifb_fix.smem_len, MEMREMAP_WB);
if (!info->screen_base) {
pr_err("efifb: abort, cannot remap video memory 0x%x @ 0x%lx\n",
efifb_fix.smem_len, efifb_fix.smem_start);
err = -EIO;
goto err_release_fb;
}
efifb_show_boot_graphics(info);
pr_info("efifb: framebuffer at 0x%lx, using %dk, total %dk\n",
efifb_fix.smem_start, size_remap/1024, size_total/1024);
pr_info("efifb: mode is %dx%dx%d, linelength=%d, pages=%d\n",
efifb_defined.xres, efifb_defined.yres,
efifb_defined.bits_per_pixel, efifb_fix.line_length,
screen_info.pages);
efifb_defined.xres_virtual = efifb_defined.xres;
efifb_defined.yres_virtual = efifb_fix.smem_len /
efifb_fix.line_length;
pr_info("efifb: scrolling: redraw\n");
efifb_defined.yres_virtual = efifb_defined.yres;
/* some dummy values for timing to make fbset happy */
efifb_defined.pixclock = 10000000 / efifb_defined.xres *
1000 / efifb_defined.yres;
efifb_defined.left_margin = (efifb_defined.xres / 8) & 0xf8;
efifb_defined.hsync_len = (efifb_defined.xres / 8) & 0xf8;
efifb_defined.red.offset = screen_info.red_pos;
efifb_defined.red.length = screen_info.red_size;
efifb_defined.green.offset = screen_info.green_pos;
efifb_defined.green.length = screen_info.green_size;
efifb_defined.blue.offset = screen_info.blue_pos;
efifb_defined.blue.length = screen_info.blue_size;
efifb_defined.transp.offset = screen_info.rsvd_pos;
efifb_defined.transp.length = screen_info.rsvd_size;
pr_info("efifb: %s: "
"size=%d:%d:%d:%d, shift=%d:%d:%d:%d\n",
"Truecolor",
screen_info.rsvd_size,
screen_info.red_size,
screen_info.green_size,
screen_info.blue_size,
screen_info.rsvd_pos,
screen_info.red_pos,
screen_info.green_pos,
screen_info.blue_pos);
efifb_fix.ypanstep = 0;
efifb_fix.ywrapstep = 0;
info->fbops = &efifb_ops;
info->var = efifb_defined;
info->fix = efifb_fix;
info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
orientation = drm_get_panel_orientation_quirk(efifb_defined.xres,
efifb_defined.yres);
switch (orientation) {
default:
info->fbcon_rotate_hint = FB_ROTATE_UR;
break;
case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
info->fbcon_rotate_hint = FB_ROTATE_UD;
break;
case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
info->fbcon_rotate_hint = FB_ROTATE_CCW;
break;
case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
info->fbcon_rotate_hint = FB_ROTATE_CW;
break;
}
err = sysfs_create_groups(&dev->dev.kobj, efifb_groups);
if (err) {
pr_err("efifb: cannot add sysfs attrs\n");
goto err_unmap;
}
err = fb_alloc_cmap(&info->cmap, 256, 0);
if (err < 0) {
pr_err("efifb: cannot allocate colormap\n");
goto err_groups;
}
err = register_framebuffer(info);
if (err < 0) {
pr_err("efifb: cannot register framebuffer\n");
goto err_fb_dealoc;
}
fb_info(info, "%s frame buffer device\n", info->fix.id);
return 0;
err_fb_dealoc:
fb_dealloc_cmap(&info->cmap);
err_groups:
sysfs_remove_groups(&dev->dev.kobj, efifb_groups);
err_unmap:
if (mem_flags & (EFI_MEMORY_UC | EFI_MEMORY_WC))
iounmap(info->screen_base);
else
memunmap(info->screen_base);
err_release_fb:
framebuffer_release(info);
err_release_mem:
if (request_mem_succeeded)
release_mem_region(efifb_fix.smem_start, size_total);
return err;
}
static int efifb_remove(struct platform_device *pdev)
{
struct fb_info *info = platform_get_drvdata(pdev);
unregister_framebuffer(info);
sysfs_remove_groups(&pdev->dev.kobj, efifb_groups);
framebuffer_release(info);
return 0;
}
static struct platform_driver efifb_driver = {
.driver = {
.name = "efi-framebuffer",
},
.probe = efifb_probe,
.remove = efifb_remove,
};
builtin_platform_driver(efifb_driver);
drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it 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 <ard.biesheuvel@linaro.org> Reviewed-by: Peter Jones <pjones@redhat.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170818194947.19347-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-08-19 03:49:40 +08:00
#if defined(CONFIG_PCI)
drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it 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 <ard.biesheuvel@linaro.org> Reviewed-by: Peter Jones <pjones@redhat.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170818194947.19347-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-08-19 03:49:40 +08:00
static void record_efifb_bar_resource(struct pci_dev *dev, int idx, u64 offset)
{
u16 word;
drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it 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 <ard.biesheuvel@linaro.org> Reviewed-by: Peter Jones <pjones@redhat.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170818194947.19347-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-08-19 03:49:40 +08:00
efifb_pci_dev = dev;
pci_read_config_word(dev, PCI_COMMAND, &word);
if (!(word & PCI_COMMAND_MEMORY)) {
pci_dev_disabled = true;
dev_err(&dev->dev,
"BAR %d: assigned to efifb but device is disabled!\n",
idx);
return;
}
drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it 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 <ard.biesheuvel@linaro.org> Reviewed-by: Peter Jones <pjones@redhat.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170818194947.19347-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-08-19 03:49:40 +08:00
bar_resource = &dev->resource[idx];
bar_offset = offset;
dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
}
static void efifb_fixup_resources(struct pci_dev *dev)
{
u64 base = screen_info.lfb_base;
u64 size = screen_info.lfb_size;
int i;
drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it 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 <ard.biesheuvel@linaro.org> Reviewed-by: Peter Jones <pjones@redhat.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170818194947.19347-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-08-19 03:49:40 +08:00
if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
return;
if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
base |= (u64)screen_info.ext_lfb_base << 32;
if (!base)
return;
for (i = 0; i < PCI_STD_NUM_BARS; i++) {
struct resource *res = &dev->resource[i];
if (!(res->flags & IORESOURCE_MEM))
continue;
if (res->start <= base && res->end >= base + size - 1) {
drivers/fbdev/efifb: Allow BAR to be moved instead of claiming it 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 <ard.biesheuvel@linaro.org> Reviewed-by: Peter Jones <pjones@redhat.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170818194947.19347-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-08-19 03:49:40 +08:00
record_efifb_bar_resource(dev, i, base - res->start);
break;
}
}
}
DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY,
16, efifb_fixup_resources);
#endif