kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/drivers/video/fbdev/efifb.c

605 lines
16 KiB
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 15:07:57 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Do not use struct fb_info.apertures Acquire ownership of the firmware scanout buffer by calling Linux' aperture helpers. Remove the use of struct fb_info.apertures and do not set FBINFO_MISC_FIRMWARE; both of which previously configured buffer ownership. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-12-tzimmermann@suse.de
2022-12-19 17:05:09 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
x86/efi/efifb: Move DMI based quirks handling out of generic code 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 <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Acked-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> 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 <mingo@kernel.org>
2016-04-25 21:06:50 +01:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
x86/efi/efifb: Move DMI based quirks handling out of generic code 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 <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Acked-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> 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 <mingo@kernel.org>
2016-04-25 21:06:50 +01:00
efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk 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 <b.zolnierkie@samsung.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-7-hdegoede@redhat.com
2017-11-25 20:35:52 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
efifb: BGRT: Add nobgrt option 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 <dh.herrmann@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-09-26 18:11:22 +02:00
efifb: Fix mismatched request/release_mem_region Signed-off-by: Andy Lutomirski <luto@mit.edu> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2011-05-26 10:13:32 -04:00
fbdev/efifb: Honour UEFI memory map attributes when mapping the FB 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 <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180711094040.12506-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 11:40:40 +02:00
efifb: Fix mismatched request/release_mem_region Signed-off-by: Andy Lutomirski <luto@mit.edu> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2011-05-26 10:13:32 -04:00
fbdev/efifb: Add struct efifb_par for driver data The efifb_par structure holds the palette for efifb. It will also be useful for storing the device's aperture range. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-11-tzimmermann@suse.de
2022-12-19 17:05:08 +01:00
fbdev/efifb: Do not use struct fb_info.apertures Acquire ownership of the firmware scanout buffer by calling Linux' aperture helpers. Remove the use of struct fb_info.apertures and do not set FBINFO_MISC_FIRMWARE; both of which previously configured buffer ownership. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-12-tzimmermann@suse.de
2022-12-19 17:05:09 +01:00
fbdev/efifb: Add struct efifb_par for driver data The efifb_par structure holds the palette for efifb. It will also be useful for storing the device's aperture range. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-11-tzimmermann@suse.de
2022-12-19 17:05:08 +01:00
Drivers: video: remove __dev* attributes. CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit from these drivers. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-21 13:07:39 -08:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
Drivers: video: remove __dev* attributes. CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit from these drivers. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-21 13:07:39 -08:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Fix 16 color palette entry calculation 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 <mstaudt@suse.de> Acked-By: Peter Jones <pjones@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-06-13 19:15:59 +02:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
efifb: BGRT: Do not copy the boot graphics for non native resolutions 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-24 19:11:28 +02:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: BGRT: Do not copy the boot graphics for non native resolutions 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-24 19:11:28 +02:00
efifb: BGRT: Improve efifb_bgrt_sanity_check For various reasons, at least with x86 EFI firmwares, the xoffset and yoffset in the BGRT info are not always reliable. Extensive testing has shown that when the info is correct, the BGRT image is always exactly centered horizontally (the yoffset variable is more variable and not always predictable). This commit simplifies / improves the bgrt_sanity_check to simply check that the BGRT image is exactly centered horizontally and skips (re)drawing it when it is not. This fixes the BGRT image sometimes being drawn in the wrong place. Cc: stable@vger.kernel.org Fixes: 88fe4ceb2447 ("efifb: BGRT: Do not copy the boot graphics for non native resolutions") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: Peter Jones <pjones@redhat.com>, Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190721131918.10115-1-hdegoede@redhat.com
2019-07-21 15:19:18 +02:00
efifb: BGRT: Do not copy the boot graphics for non native resolutions 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-24 19:11:28 +02:00
efifb: BGRT: Improve efifb_bgrt_sanity_check For various reasons, at least with x86 EFI firmwares, the xoffset and yoffset in the BGRT info are not always reliable. Extensive testing has shown that when the info is correct, the BGRT image is always exactly centered horizontally (the yoffset variable is more variable and not always predictable). This commit simplifies / improves the bgrt_sanity_check to simply check that the BGRT image is exactly centered horizontally and skips (re)drawing it when it is not. This fixes the BGRT image sometimes being drawn in the wrong place. Cc: stable@vger.kernel.org Fixes: 88fe4ceb2447 ("efifb: BGRT: Do not copy the boot graphics for non native resolutions") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: Peter Jones <pjones@redhat.com>, Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190721131918.10115-1-hdegoede@redhat.com
2019-07-21 15:19:18 +02:00
efifb: BGRT: Do not copy the boot graphics for non native resolutions 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-24 19:11:28 +02:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: BGRT: Do not copy the boot graphics for non native resolutions 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-24 19:11:28 +02:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
video: fbdev: efifb: Fix set but not used warning for screen_pitch screen_pitch was asssigned a value which was never used. Drop it to fix the warning Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Peter Jones <pjones@redhat.com> Cc: linux-fbdev@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20201206190247.1861316-12-sam@ravnborg.org
2020-12-06 20:02:45 +01:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
efifb: BGRT: Add nobgrt option 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 <dh.herrmann@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-09-26 18:11:22 +02:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
efifb: BGRT: Add check for new BGRT status field rotation bits Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer reserved. These bits are now used to indicate if the image needs to be rotated before being displayed. The efifb code does not support rotating the image before copying it to the screen. This commit adds a check for these new bits and if they are set leaves the fb contents as is instead of trying to use the un-rotated BGRT image. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Peter Jones <pjones@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2019-06-21 15:13:14 +02:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
efifb: BGRT: Do not copy the boot graphics for non native resolutions 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-24 19:11:28 +02:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove The driver is calling framebuffer_release() in its .remove callback, but this will cause the struct fb_info to be freed too early. Since it could be that a reference is still hold to it if user-space opened the fbdev. This would lead to a use-after-free error if the framebuffer device was unregistered but later a user-space process tries to close the fbdev fd. To prevent this, move the framebuffer_release() call to fb_ops.fb_destroy instead of doing it in the driver's .remove callback. Strictly speaking, the code flow in the driver is still wrong because all the hardware cleanupd (i.e: iounmap) should be done in .remove while the software cleanup (i.e: releasing the framebuffer) should be done in the .fb_destroy handler. But this at least makes to match the behavior before commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal"). Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal") Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220505220540.366218-1-javierm@redhat.com
2022-05-06 00:05:40 +02:00
efifb: fix framebuffer handoff Commit 4410f3910947dcea8672280b3adecd53cec4e85e ("fbdev: add support for handoff from firmware to hw framebuffers") didn't add fb_destroy operation to efifb. Fix it and change aperture_size to match size passed to request_mem_region. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=15151 Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Reported-by: Alex Zhavnerchik <alex.vizor@gmail.com> Tested-by: Alex Zhavnerchik <alex.vizor@gmail.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-02-22 12:44:22 -08:00
fbdev/efifb: Do not use struct fb_info.apertures Acquire ownership of the firmware scanout buffer by calling Linux' aperture helpers. Remove the use of struct fb_info.apertures and do not set FBINFO_MISC_FIRMWARE; both of which previously configured buffer ownership. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-12-tzimmermann@suse.de
2022-12-19 17:05:09 +01:00
fbdev/efifb: Honour UEFI memory map attributes when mapping the FB 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 <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180711094040.12506-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 11:40:40 +02:00
fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove The driver is calling framebuffer_release() in its .remove callback, but this will cause the struct fb_info to be freed too early. Since it could be that a reference is still hold to it if user-space opened the fbdev. This would lead to a use-after-free error if the framebuffer device was unregistered but later a user-space process tries to close the fbdev fd. To prevent this, move the framebuffer_release() call to fb_ops.fb_destroy instead of doing it in the driver's .remove callback. Strictly speaking, the code flow in the driver is still wrong because all the hardware cleanupd (i.e: iounmap) should be done in .remove while the software cleanup (i.e: releasing the framebuffer) should be done in the .fb_destroy handler. But this at least makes to match the behavior before commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal"). Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal") Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220505220540.366218-1-javierm@redhat.com
2022-05-06 00:05:40 +02:00
efifb: Fix mismatched request/release_mem_region Signed-off-by: Andy Lutomirski <luto@mit.edu> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2011-05-26 10:13:32 -04:00
fbdev/efifb: Do not use struct fb_info.apertures Acquire ownership of the firmware scanout buffer by calling Linux' aperture helpers. Remove the use of struct fb_info.apertures and do not set FBINFO_MISC_FIRMWARE; both of which previously configured buffer ownership. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-12-tzimmermann@suse.de
2022-12-19 17:05:09 +01:00
Release efifb's colormap in efifb_destroy() This was found by Alexandra Kossovsky, who noted this traceback from kmemleak: > unreferenced object 0xffff880216fcfe00 (size 512): > comm "swapper/0", pid 1, jiffies 4294895429 (age 1415.320s) > hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 aa aa aa aa aa aa aa aa ................ > 55 55 55 55 55 55 55 55 ff ff ff ff ff ff ff ff UUUUUUUU........ > backtrace: > [<ffffffff813e415c>] kmemleak_alloc+0x21/0x3e > [<ffffffff8111c17f>] > kmemleak_alloc_recursive.constprop.57+0x16/0x18 > [<ffffffff8111e63b>] __kmalloc+0xf9/0x144 > [<ffffffff8123d9cf>] fb_alloc_cmap_gfp+0x47/0xe1 > [<ffffffff8123da77>] fb_alloc_cmap+0xe/0x10 > [<ffffffff81aff40a>] efifb_probe+0x3e9/0x48f > [<ffffffff812c566f>] platform_drv_probe+0x34/0x5e > [<ffffffff812c3e6d>] driver_probe_device+0x98/0x1b4 > [<ffffffff812c3fd7>] __driver_attach+0x4e/0x6f > [<ffffffff812c25bf>] bus_for_each_dev+0x57/0x8a > [<ffffffff812c3984>] driver_attach+0x19/0x1b > [<ffffffff812c362b>] bus_add_driver+0xde/0x201 > [<ffffffff812c453f>] driver_register+0x8c/0x110 > [<ffffffff812c510d>] platform_driver_register+0x41/0x43 > [<ffffffff812c5127>] platform_driver_probe+0x18/0x8a > [<ffffffff81aff002>] efifb_init+0x276/0x295 Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-07-25 11:48:11 -04:00
fbdev: efifb: Fix a use-after-free due early fb_info cleanup Commit d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove") attempted to fix a use-after-free error due driver freeing the fb_info in the .remove handler instead of doing it in .fb_destroy. But ironically that change introduced yet another use-after-free since the fb_info was still used after the free. This should fix for good by freeing the fb_info at the end of the handler. Fixes: d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Thomas Zimmermann <tzimemrmann@suse.de> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220506132225.588379-1-javierm@redhat.com
2022-05-06 15:22:25 +02:00
efifb: fix framebuffer handoff Commit 4410f3910947dcea8672280b3adecd53cec4e85e ("fbdev: add support for handoff from firmware to hw framebuffers") didn't add fb_destroy operation to efifb. Fix it and change aperture_size to match size passed to request_mem_region. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=15151 Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Reported-by: Alex Zhavnerchik <alex.vizor@gmail.com> Tested-by: Alex Zhavnerchik <alex.vizor@gmail.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-02-22 12:44:22 -08:00
video: constify fb ops across all drivers Now that the fbops member of struct fb_info is const, we can start making the ops const as well. This does not cover all drivers; some actually modify the fbops struct, for example to adjust for different configurations, and others do more involved things that I'd rather not touch in practically obsolete drivers. Mostly this is the low hanging fruit where we can add "const" and be done with it. v3: - un-constify atyfb, mb862xx, nvidia and uvesabf (0day) v2: - fix typo (Christophe de Dinechin) - use "static const" instead of "const static" in mx3fb.c - also constify smscufx.c Cc: linux-fbdev@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ce67f14435f3af498f2e8bf35ce4be11f7504132.1575390740.git.jani.nikula@intel.com
2019-12-03 18:38:50 +02:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Use fbdev I/O helpers Set struct fb_ops and with FB_DEFAULT_IOMEM_OPS, fbdev's initializer for I/O memory. Sets the callbacks to the cfb_ and fb_io_ functions. Select the correct modules with Kconfig's FB_IOMEM_HELPERS token. The macro and token set the currently selected values, so there is no functional change. v3: * use _IOMEM_ in commit message v2: * updated to use _IOMEM_ tokens Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Helge Deller <deller@gmx.de> Cc: Peter Jones <pjones@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230803184034.6456-10-tzimmermann@suse.de
2023-08-03 20:35:34 +02:00
efifb: fix framebuffer handoff Commit 4410f3910947dcea8672280b3adecd53cec4e85e ("fbdev: add support for handoff from firmware to hw framebuffers") didn't add fb_destroy operation to efifb. Fix it and change aperture_size to match size passed to request_mem_region. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=15151 Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Reported-by: Alex Zhavnerchik <alex.vizor@gmail.com> Tested-by: Alex Zhavnerchik <alex.vizor@gmail.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Huang Ying <ying.huang@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-02-22 12:44:22 -08:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev: efifb: Change the return value type to void efifb_setup() doesn't need to return a value. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Signed-off-by: Helge Deller <deller@gmx.de>
2025-01-03 11:26:33 +08:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
efifb: Implement vga_default_device() (v2) EFI doesn't typically make use of the legacy VGA ROM, but it may still be configured to pass that through to a given video device. This may lead to an inaccurate choice of default video device. Add support to efifb to pick out the correct active video device. v2: fix if->ifdef Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: hpa@zytor.com Cc: matt.fleming@intel.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-04-16 16:26:05 -04:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
x86/efi/efifb: Move DMI based quirks handling out of generic code 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 <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Acked-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> 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 <mingo@kernel.org>
2016-04-25 21:06:50 +01:00
efifb: Implement vga_default_device() (v2) EFI doesn't typically make use of the legacy VGA ROM, but it may still be configured to pass that through to a given video device. This may lead to an inaccurate choice of default video device. Add support to efifb to pick out the correct active video device. v2: fix if->ifdef Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: hpa@zytor.com Cc: matt.fleming@intel.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-04-16 16:26:05 -04:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Implement vga_default_device() (v2) EFI doesn't typically make use of the legacy VGA ROM, but it may still be configured to pass that through to a given video device. This may lead to an inaccurate choice of default video device. Add support to efifb to pick out the correct active video device. v2: fix if->ifdef Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: hpa@zytor.com Cc: matt.fleming@intel.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-04-16 16:26:05 -04:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Implement vga_default_device() (v2) EFI doesn't typically make use of the legacy VGA ROM, but it may still be configured to pass that through to a given video device. This may lead to an inaccurate choice of default video device. Add support to efifb to pick out the correct active video device. v2: fix if->ifdef Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: hpa@zytor.com Cc: matt.fleming@intel.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-04-16 16:26:05 -04:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Implement vga_default_device() (v2) EFI doesn't typically make use of the legacy VGA ROM, but it may still be configured to pass that through to a given video device. This may lead to an inaccurate choice of default video device. Add support to efifb to pick out the correct active video device. v2: fix if->ifdef Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: hpa@zytor.com Cc: matt.fleming@intel.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-04-16 16:26:05 -04:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
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-07-31 18:45:41 +02:00
fbdev/efifb: Honour UEFI memory map attributes when mapping the FB 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 <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180711094040.12506-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 11:40:40 +02:00
efifb: BGRT: Add nobgrt option 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 <dh.herrmann@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-09-26 18:11:22 +02:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Add support for 64-bit frame buffer addresses 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 <chad.page@znyx.com> Cc: Pete Hawkins <pete.hawkins@znyx.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-08-25 16:32:55 +01:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Add support for 64-bit frame buffer addresses 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 <chad.page@znyx.com> Cc: Pete Hawkins <pete.hawkins@znyx.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-08-25 16:32:55 +01:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Add support for 64-bit frame buffer addresses 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 <chad.page@znyx.com> Cc: Pete Hawkins <pete.hawkins@znyx.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-08-25 16:32:55 +01:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Add support for 64-bit frame buffer addresses 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 <chad.page@znyx.com> Cc: Pete Hawkins <pete.hawkins@znyx.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-08-25 16:32:55 +01:00
efifb: Show framebuffer layout as device attributes 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 <ard.biesheuvel@linaro.org> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161018143318.15673-8-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18 15:33:17 +01:00
fbdev: efifb: Use driver-private screen_info for sysfs Since commit b9cfd1d271ab ("fbdev/efifb: Use screen_info pointer from device") efifb uses a local copy of screen_info and applies its modifications there. Adapt the sysfs attributes to also work with the custom copy instead of the unmodified platform data. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Helge Deller <deller@gmx.de>
2024-08-27 17:25:16 +02:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Show framebuffer layout as device attributes 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 <ard.biesheuvel@linaro.org> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161018143318.15673-8-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18 15:33:17 +01:00
fbdev: efifb: bind to efi-framebuffer Instead of creating a dummy device, we now bind to the efi-fb device which is provided by x86 initialization code. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1375445127-15480-8-git-send-email-dh.herrmann@gmail.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 14:05:26 +02:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Use screen_info pointer from device Use the screen_info instance from the device instead of dereferencing the global screen_info state. Decouples the driver from per-architecture code. Duplicated the screen_info data, so that efifb can modify it at will. v2: * comment on devm_kmemdup() usage (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-3-tzimmermann@suse.de
2023-12-06 14:50:27 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Add struct efifb_par for driver data The efifb_par structure holds the palette for efifb. It will also be useful for storing the device's aperture range. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-11-tzimmermann@suse.de
2022-12-19 17:05:08 +01:00
efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk 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 <b.zolnierkie@samsung.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-7-hdegoede@redhat.com
2017-11-25 20:35:52 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev: efifb: bind to efi-framebuffer Instead of creating a dummy device, we now bind to the efi-fb device which is provided by x86 initialization code. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1375445127-15480-8-git-send-email-dh.herrmann@gmail.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 14:05:26 +02:00
fbdev/efifb: Honour UEFI memory map attributes when mapping the FB 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 <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180711094040.12506-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 11:40:40 +02:00
fbdev: efifb: bind to efi-framebuffer Instead of creating a dummy device, we now bind to the efi-fb device which is provided by x86 initialization code. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1375445127-15480-8-git-send-email-dh.herrmann@gmail.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 14:05:26 +02:00
fbdev/efifb: Use screen_info pointer from device Use the screen_info instance from the device instead of dereferencing the global screen_info state. Decouples the driver from per-architecture code. Duplicated the screen_info data, so that efifb can modify it at will. v2: * comment on devm_kmemdup() usage (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-3-tzimmermann@suse.de
2023-12-06 14:50:27 +01:00
fbdev: efifb: Use driver-private screen_info for sysfs Since commit b9cfd1d271ab ("fbdev/efifb: Use screen_info pointer from device") efifb uses a local copy of screen_info and applies its modifications there. Adapt the sysfs attributes to also work with the custom copy instead of the unmodified platform data. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Helge Deller <deller@gmx.de>
2024-08-27 17:25:16 +02:00
fbdev/efifb: Do not track parent device status There will be no EFI framebuffer device for disabled parent devices and thus we never probe efifb in that case. Hence remove the tracking code from efifb. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-7-tzimmermann@suse.de
2024-02-12 10:06:14 +01:00
fbdev: efifb: bind to efi-framebuffer Instead of creating a dummy device, we now bind to the efi-fb device which is provided by x86 initialization code. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1375445127-15480-8-git-send-email-dh.herrmann@gmail.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 14:05:26 +02:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
fbdev: efifb: bind to efi-framebuffer Instead of creating a dummy device, we now bind to the efi-fb device which is provided by x86 initialization code. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1375445127-15480-8-git-send-email-dh.herrmann@gmail.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 14:05:26 +02:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
fbdev: efifb: bind to efi-framebuffer Instead of creating a dummy device, we now bind to the efi-fb device which is provided by x86 initialization code. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1375445127-15480-8-git-send-email-dh.herrmann@gmail.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 14:05:26 +02:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: exit if framebuffer address is invalid efifb will attempt to ioremap a framebuffer even if its starting address is 0, failing and causing an ugly backtrace in the process. Exit before probing if this is the case. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-13 14:39:44 -07:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Remove framebuffer relocation tracking If the firmware framebuffer has been reloacted, the sysfb code fixes the screen_info state before it creates the framebuffer's platform device. Efifb will automatically receive a screen_info with updated values. Hence remove the tracking from efifb. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Sui Jingfeng <sui.jingfeng@linux.dev> Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-9-tzimmermann@suse.de
2024-02-12 10:06:16 +01:00
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-18 20:49:40 +01:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
efifb: Fix mismatched request/release_mem_region Signed-off-by: Andy Lutomirski <luto@mit.edu> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2011-05-26 10:13:32 -04:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb: Show framebuffer layout as device attributes 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 <ard.biesheuvel@linaro.org> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161018143318.15673-8-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18 15:33:17 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Add struct efifb_par for driver data The efifb_par structure holds the palette for efifb. It will also be useful for storing the device's aperture range. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-11-tzimmermann@suse.de
2022-12-19 17:05:08 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Add struct efifb_par for driver data The efifb_par structure holds the palette for efifb. It will also be useful for storing the device's aperture range. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-11-tzimmermann@suse.de
2022-12-19 17:05:08 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Do not use struct fb_info.apertures Acquire ownership of the firmware scanout buffer by calling Linux' aperture helpers. Remove the use of struct fb_info.apertures and do not set FBINFO_MISC_FIRMWARE; both of which previously configured buffer ownership. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-12-tzimmermann@suse.de
2022-12-19 17:05:09 +01:00
fbdev: add support for handoff from firmware to hw framebuffers With KMS we have ran into an issue where we really want the KMS fb driver to be the one running the console, so panics etc can be shown by switching out of X etc. However with vesafb/efifb built-in, we end up with those on fb0 and the KMS fb driver on fb1, driving the same piece of hw, so this adds an fb info flag to denote a firmware fbdev, and adds a new aperture base/size range which can be compared when the hw drivers are installed to see if there is a conflict with a firmware driver, and if there is the firmware driver is unregistered and the hw driver takes over. It uses new aperture_base/size members instead of comparing on the fix smem_start/length, as smem_start/length might for example only cover the first 1MB of the PCI aperture, and we could allocate the kms fb from 8MB into the aperture, thus they would never overlap. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Dave Airlie <airlied@redhat.com> Acked-by: Peter Jones <pjones@redhat.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-16 15:34:38 -07:00
efi: avoid error message when booting under Xen efifb_probe() will issue an error message in case the kernel is booted as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid that message by calling efi_mem_desc_lookup() only if EFI_MEMMAP is set. Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB") Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2020-07-10 16:16:51 +02:00
efifb: Omit memory map check on legacy boot Since the following commit: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB") efifb_probe() checks its memory range via efi_mem_desc_lookup(), and this leads to a spurious error message: EFI_MEMMAP is not enabled at every boot on KVM. This is quite annoying since the error message appears even if you set "quiet" boot option. Since this happens on legacy boot, which strangely enough exposes a EFI framebuffer via screen_info, let's double check that we are doing an EFI boot before attempting to access the EFI memory map. Reported-by: Takashi Iwai <tiwai@suse.de> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> 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 Link: http://lkml.kernel.org/r/20190328193429.21373-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-03-28 20:34:26 +01:00
fbdev/efifb: Honour UEFI memory map attributes when mapping the FB 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 <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180711094040.12506-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 11:40:40 +02:00
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-16 23:31:59 +02:00
fbdev/efifb: Honour UEFI memory map attributes when mapping the FB 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 <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180711094040.12506-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 11:40:40 +02:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Honour UEFI memory map attributes when mapping the FB 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 <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180711094040.12506-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 11:40:40 +02:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
efifb: Copy the ACPI BGRT boot graphics to the framebuffer 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 <hdegoede@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-03 17:43:10 +02:00
efifb: Show framebuffer layout as device attributes 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 <ard.biesheuvel@linaro.org> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161018143318.15673-8-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18 15:33:17 +01:00
efifb: Don't show the mapping VA The framebuffer mapping virtual address leaks information about the kernel memory layout. Stop logging it. Cc: Peter Jones <pjones@redhat.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-05-11 16:57:47 -07:00
efifb: Show framebuffer layout as device attributes 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 <ard.biesheuvel@linaro.org> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161018143318.15673-8-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18 15:33:17 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb: Show framebuffer layout as device attributes 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 <ard.biesheuvel@linaro.org> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161018143318.15673-8-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18 15:33:17 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb: Show framebuffer layout as device attributes 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 <ard.biesheuvel@linaro.org> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161018143318.15673-8-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18 15:33:17 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Replace references to global screen_info by local pointer Get the global screen_info's address once and access the data via this pointer. Limits the use of global state. v3: * use const screen_info in several places (Sui) * fix build for deferred takeover (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-2-tzimmermann@suse.de
2023-12-06 14:50:26 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk 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 <b.zolnierkie@samsung.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-7-hdegoede@redhat.com
2017-11-25 20:35:52 +01:00
efifb: Show framebuffer layout as device attributes 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 <ard.biesheuvel@linaro.org> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161018143318.15673-8-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18 15:33:17 +01:00
fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Helge Deller <deller@gmx.de>
2024-08-27 17:25:13 +02:00
efifb: Show framebuffer layout as device attributes 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 <ard.biesheuvel@linaro.org> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161018143318.15673-8-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18 15:33:17 +01:00
fbdev/efifb: Release PCI device's runtime PM ref during FB destroy Atm the EFI FB platform driver gets a runtime PM reference for the associated GFX PCI device during probing the EFI FB platform device and releases it only when the platform device gets unbound. When fbcon switches to the FB provided by the PCI device's driver (for instance i915/drmfb), the EFI FB will get only unregistered without the EFI FB platform device getting unbound, keeping the runtime PM reference acquired during the platform device probing. This reference will prevent the PCI driver from runtime suspending the device. Fix this by releasing the RPM reference from the EFI FB's destroy hook, called when the FB gets unregistered. While at it assert that pm_runtime_get_sync() didn't fail. v2: - Move pm_runtime_get_sync() before register_framebuffer() to avoid its race wrt. efifb_destroy()->pm_runtime_put(). (Daniel) - Assert that pm_runtime_get_sync() didn't fail. - Clarify commit message wrt. platform/PCI device/driver and driver removal vs. device unbinding. Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0") Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1) Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210809133146.2478382-1-imre.deak@intel.com
2021-08-09 16:31:46 +03:00
fbdev/efifb: Do not use struct fb_info.apertures Acquire ownership of the firmware scanout buffer by calling Linux' aperture helpers. Remove the use of struct fb_info.apertures and do not set FBINFO_MISC_FIRMWARE; both of which previously configured buffer ownership. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-12-tzimmermann@suse.de
2022-12-19 17:05:09 +01:00
fbdev/efifb: Remove PM for parent device The EFI device has the correct parent device set. This allows Linux to handle the power management internally. Hence, remove the manual PM management for the parent device from efifb. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-5-tzimmermann@suse.de
2024-02-12 10:06:12 +01:00
fbdev/efifb: Do not use struct fb_info.apertures Acquire ownership of the firmware scanout buffer by calling Linux' aperture helpers. Remove the use of struct fb_info.apertures and do not set FBINFO_MISC_FIRMWARE; both of which previously configured buffer ownership. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-12-tzimmermann@suse.de
2022-12-19 17:05:09 +01:00
fbdev: efifb: Use devm_register_framebuffer() This simplifies the error handling. Also the drvdata slot is now unused and can be used for other usecases. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Helge Deller <deller@gmx.de>
2024-08-27 17:25:15 +02:00
efifb: Show framebuffer layout as device attributes 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 <ard.biesheuvel@linaro.org> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161018143318.15673-8-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-10-18 15:33:17 +01:00
fbdev/efifb: Remove PM for parent device The EFI device has the correct parent device set. This allows Linux to handle the power management internally. Hence, remove the manual PM management for the parent device from efifb. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-5-tzimmermann@suse.de
2024-02-12 10:06:12 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
framebuffer: Use fb_<level> Neaten and shorten the code using the new fb_<level> macros. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-09-19 18:35:55 -07:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Remove PM for parent device The EFI device has the correct parent device set. This allows Linux to handle the power management internally. Hence, remove the manual PM management for the parent device from efifb. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-5-tzimmermann@suse.de
2024-02-12 10:06:12 +01:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev/efifb: Honour UEFI memory map attributes when mapping the FB 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 <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180711094040.12506-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 11:40:40 +02:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb: Fix mismatched request/release_mem_region Signed-off-by: Andy Lutomirski <luto@mit.edu> Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2011-05-26 10:13:32 -04:00
efifb/imacfb consolidation + hardware support Remove imacfb entirely, merging its DMI table into the (otherwise very similar) efifb driver. This also adds hardware support for many of the newer Intel Apple hardware. This has been fairly well tested; we've been shipping it in Fedora for some time. Signed-off-by: Peter Jones <pjones@redhat.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: Jaya Kumar <jayakumar.lkml@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-15 22:03:43 -07:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev: efifb: bind to efi-framebuffer Instead of creating a dummy device, we now bind to the efi-fb device which is provided by x86 initialization code. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1375445127-15480-8-git-send-email-dh.herrmann@gmail.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 14:05:26 +02:00
fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Helge Deller <deller@gmx.de>
2024-08-27 17:25:13 +02:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
fbdev: efifb: bind to efi-framebuffer Instead of creating a dummy device, we now bind to the efi-fb device which is provided by x86 initialization code. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1375445127-15480-8-git-send-email-dh.herrmann@gmail.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-08-02 14:05:26 +02:00
x86_64 EFI boot support: EFI frame buffer driver This patch adds Graphics Output Protocol support to the kernel. UEFI2.0 spec deprecates Universal Graphics Adapter (UGA) protocol and only Graphics Output Protocol (GOP) is produced. Therefore, the boot loader needs to query the UEFI firmware with appropriate Output Protocol and pass the video information to the kernel. As a result of GOP protocol, an EFI framebuffer driver is needed for displaying console messages. The patch adds a EFI framebuffer driver. The EFI frame buffer driver in this patch is based on the Intel Mac framebuffer driver. The ELILO bootloader takes care of passing the video information as appropriate for EFI firmware. The framebuffer driver has been tested in i386 kernel and x86_64 kernel on EFI platform. Signed-off-by: Chandramouli Narayanan <mouli@linux.intel.com> Signed-off-by: Huang Ying <ying.huang@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andi Kleen <ak@suse.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-28 16:21:55 -08:00
efifb: Use builtin_platform_driver and drop unused includes 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 <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Acked-by: Peter Jones <pjones@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> 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 <mingo@kernel.org>
2016-04-25 21:06:51 +01:00