The majority of the DMI checks in efifb are for cases where the bootloader
has provided invalid information. However, on some machines the overrides
may do more harm than good due to configuration differences between machines
with the same machine identifier. It turns out that it's possible for the
bootloader to get the correct information on GOP-based systems, but we
can't guarantee that the kernel's being booted with one that's been updated
to do so. Add support for a capabilities flag that can be set by the
bootloader, and skip the DMI checks in that case. Additionally, set this
flag in the UEFI stub code.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
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>
platform_device_unregister() needs to unregister the device, not the
driver.
Signed-off-by: Wanlong Gao <wanlong.gao@gmail.com>
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
Acked-by: Andy Lutomirski <luto@mit.edu>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Both were buggy: bind would happily scribble over a real graphics
device and unbind wouldn't destroy the framebuffer. Hotplugging
efifb makes no sense anyway, so just disable it.
As an added benefit, we save some runtime memory.
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>
Running fbcon on an uncached framebuffer is remarkably slow. So try
to enable write combining in efifb.
Without this patch, it takes 5.8 seconds from efifb probe to i915
probe (default options; no plymouth or quiet mode). With this patch,
it only takes 1.7 seconds. That means we wasted over 4 seconds just
writing to UC memory.
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>
drivers/video/efifb.c:247: warning: cast to pointer from integer of different size
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
The 11" Macbook Air appears to claim that its stride is 1366, when it's
actually 2048. Override it.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Some machines apparently give us bogus linelength/stride/pitch data, so
we need to support letting the DMI table override the supplied data.
I bet you can't guess whose machines I'm talking about.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch enables the framebuffer for the AMD Radeon 6490 found in the new MacBook Pro 8,2 generation.
The framebuffer's base is located at 0x90010000, the method for obtaining it was found in the same way mentioned in https://patchwork.kernel.org/patch/91704/
Signed-off-by: Davidlohr Bueso <dave@gnu.org>
Signed-off-by: Jonathan Gonzalez <zeus@gnu.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Enable the EFI framebuffer on 14 more Macs, including the iMac11,1
iMac10,1 iMac8,1 Macmini3,1 Macmini4,1 MacBook5,1 MacBook6,1 MacBook7,1
MacBookPro2,2 MacBookPro5,2 MacBookPro5,3 MacBookPro6,1 MacBookPro6,2 and
MacBookPro7,1
Information gathered from various user submissions.
https://bugzilla.redhat.com/show_bug.cgi?id=528232http://ubuntuforums.org/showthread.php?t=1557326
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Luke Macken <lmacken@redhat.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some Apple machines have identical DMI data but different memory
configurations for the video. Given that, check that the address in our
table is actually within the range of a PCI BAR on a VGA device in the
machine.
This also fixes up the return value from set_system(), which has always
been wrong, but never resulted in bad behavior since there's only ever
been one matching entry in the dmi table.
The patch
1) stops people's machines from crashing when we get their display wrong,
which seems to be unfortunately inevitable,
2) allows us to support identical dmi data with differing video memory
configurations
This also adds me as the efifb maintainer, since I've effectively been
acting as such for quite some time.
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove 43 section mismatches by moving the two structures efifb_defined
and efifb_fix from .init.data to .devinit.data.
Also the two structure arrays dmi_system_table[] and dmi_list[] have been
moved from .data to .init.rodata and .init.data, which saves, if built-in,
some space.
On x86_64 'size -A' showed that these sections changed size:
efifb.o:
section size-old size-new
.data 1200 688
.init.data 7840 512
.init.rodata 0 7568
.devinit.data 0 256
Total 11927 11911
Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* anholt/drm-intel-next: (515 commits)
drm/i915: Fix out of tree builds
drm/i915: move fence lru to struct drm_i915_fence_reg
drm/i915: don't allow tiling changes on pinned buffers v2
drm/i915: Be extra careful about A/D matching for multifunction SDVO
drm/i915: Fix DDC bus selection for multifunction SDVO
drm/i915: cleanup mode setting before unmapping registers
drm/i915: Make fbc control wrapper functions
drm/i915: Wait for the GPU whilst shrinking, if truly desperate.
drm/i915: Use spatio-temporal dithering on PCH
[MTD] Remove zero-length files mtdbdi.c and internal.ho
pata_pcmcia / ide-cs: Fix bad hashes for Transcend and kingston IDs
libata: Fix several inaccuracies in developer's guide
slub: Fix bad boundary check in init_kmem_cache_nodes()
raid6: fix recovery performance regression
KEYS: call_sbin_request_key() must write lock keyrings before modifying them
KEYS: Use RCU dereference wrappers in keyring key type code
KEYS: find_keyring_by_name() can gain access to a freed keyring
ALSA: hda: Fix 0 dB for Packard Bell models using Conexant CX20549 (Venice)
ALSA: hda - Add quirk for Dell Inspiron 19T using a Conexant CX20582
ALSA: take tu->qlock with irqs disabled
...
It removes a hack from nouveau code which had to detect which
region to pass to kick vesafb/efifb.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Description of patch:
---------------------
This is a patch for the EFI framebuffer driver to enable the framebuffer
of the NVIDIA 9400M as found in MacBook Pro (MBP) 5,1 and up. The
framebuffer of the NVIDIA graphic cards are located at the following
addresses in memory:
9400M: 0xC0010000
9600M GT: 0xB0030000
The patch delivered right here only provides the memory location of the
framebuffer of the 9400M device. The 9600M GT is not covered. It is
assumed that the 9400M is used when powered up the MBP.
The information which device is currently powered and in use is stored in
the 64 bytes large EFI variable "gpu-power-prefs". More specifically,
byte 0x3B indicates whether 9600M GT (0x00) or 9400M (0x01) is online.
The PCI bus IDs are the following:
9400M: PCI 03:00:00
9600M GT: PCI 02:00:00
The EFI variables can be easily read-out and manipulated with "rEFIt", an
MBP specific bootloader tool. For more information on how handle rEFIt
and EFI variables please consult "http://refit.sourceforge.net" and
"http://ubuntuforums.org/archive/index.php/t-1076879.html".
IMPORTANT NOTE: The information on how to activate the 9400M device given
at "ubuntuforums.org" is not correct, since it states
gpu-power-prefs[0x3B] = 0x00 -> 9400M (PCI 02:00:00)
gpu-power-prefs[0x3B] = 0x01 -> 9600M GT (PCI 03:00:00)
Actually, the assignment of the values and the PCI bus IDs are swapped.
Suggestions:
------------
To cover framebuffers of both 9400M and 9600M GT, I would suggest to
implement a conditional on "gpu-power-prefs". Depending on the value of
byte 0x3B, the according framebuffer is selected. However, this requires
kernel access to the EFI variables.
[akpm@linux-foundation.org: rename optname, per Peter Jones]
Signed-off-by: Thomas Gerlach <t.m.gerlach@freenet.de>
Acked-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A pointer to a probe callback is passed to the core via
platform_driver_register and so the function must not disappear when the
.init sections are discarded. Otherwise (if also having HOTPLUG=y)
unbinding and binding a device to the driver via sysfs will result in an
oops as does a device being registered late.
An alternative to this patch is using platform_driver_probe instead of
platform_driver_register plus removing the pointer to the probe function
from the struct platform_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Adrian Bunk <bunk@stusta.de>
Cc: Alberto Mardegan <mardy@users.sourceforge.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andriy Skulysh <askulysh@gmail.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Chandramouli Narayanan <mouli@linux.intel.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Frans Pop <elendil@planet.nl>
Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Helge Deller <deller@gmx.de>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Ian Molton <spyro@f2s.com>
Cc: Joshua Kinard <kumba@gentoo.org>
Cc: Kaj-Michael Lang <milang@tal.org>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: linux-fbdev-devel@lists.sourceforge.net
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Magnus Damm <damm@igel.co.jp>
Cc: Martin Michlmayr <tbm@cyrius.com>
Cc: Matthias Kaehlcke <matthias@kaehlcke.net>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Pavel Machek <pavel@suse.cz>
Cc: Philipp Zabel <philipp.zabel@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Roel Kluin <roel.kluin@gmail.com>
Cc: Roland Stigge <stigge@antcom.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Vincent Sanders <vince@simtec.co.uk>
Cc: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Acked-by: James Simmons <jsimmons@infradead.org>
Acked-by: Peter Jones <pjones@redhat.com>
Acked-by: Jaya Kumar <jayakumar.lkml@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commit 4410f39109 ("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>
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>
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>
The current logic for dmi matching in efifb does not allow efifb to load
on all hardware that we can dmi match for.
For a real world example, boot with elilo (3.7 or 3.8 vanilla) and on a
Apple (MacBook) and EFI framebuffer driver will not load (you will have no
video). This specific hardware is efi v1.10, so we have UGA and not GOP.
Without special bootloader magic (i.e. extra elilo patches for UGA
graphics detection) no screen info will be passed to the kernel and as a
result efifb will not load.
This patch allows the dmi match to happen by moving it to earlier in
efifb_init, and sets the video type (in set_system) so that efifb can load
when we have a valid dmi match and already know the specifics of the
hardware.
Without this patch the efifb driver will fail to load in the event screen
info is not found and passed in by the bootloader, being that we will
never get to look for a dmi match. A primary reason for matching with dmi
is because not all bootloaders detect the video info properly. The
solution is that in the event of a dmi match, we should set
screen_info.orig_video_isVGA. Most bootloaders fail to set screen info on
Apple hardware, and this is a big problem for people who use Apple
hardware.
Tested on a MacBook SantaRosa with elilo-3.8 (vanilla) and resolves the
issue, the dmi match now works, EFI framebuffer now loads and video works.
Signed-off-by: Brian Maly <bmaly@redhat.com>
Acked-by: Huang Ying <ying.huang@intel.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Chandramouli Narayanan <mouli@linux.intel.com>
Acked-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
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>
