14 Jun, 2011
1 commit
-
platform_device_unregister() needs to unregister the device, not the
driver.Signed-off-by: Wanlong Gao
Signed-off-by: Maarten Lankhorst
Acked-by: Andy Lutomirski
Signed-off-by: Paul Mundt
02 Jun, 2011
3 commits
-
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
Signed-off-by: Peter Jones
Signed-off-by: Paul Mundt -
Signed-off-by: Andy Lutomirski
Signed-off-by: Peter Jones
Signed-off-by: Paul Mundt -
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
Signed-off-by: Peter Jones
Signed-off-by: Paul Mundt
24 May, 2011
1 commit
-
drivers/video/efifb.c:247: warning: cast to pointer from integer of different size
Signed-off-by: Konstantin Khlebnikov
Signed-off-by: Peter Jones
Signed-off-by: Paul Mundt
07 Apr, 2011
2 commits
-
The 11" Macbook Air appears to claim that its stride is 1366, when it's
actually 2048. Override it.Signed-off-by: Matthew Garrett
Signed-off-by: Peter Jones
Signed-off-by: Paul Mundt -
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
Signed-off-by: Paul Mundt
31 Mar, 2011
1 commit
-
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
Signed-off-by: Jonathan Gonzalez
Signed-off-by: Paul Mundt
23 Sep, 2010
2 commits
-
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,1Information gathered from various user submissions.
https://bugzilla.redhat.com/show_bug.cgi?id=528232
http://ubuntuforums.org/showthread.php?t=1557326[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Luke Macken
Signed-off-by: Peter Jones
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
configurationsThis also adds me as the efifb maintainer, since I've effectively been
acting as such for quite some time.Signed-off-by: Peter Jones
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Aug, 2010
1 commit
-
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 256Total 11927 11911
Signed-off-by: Henrik Kretzschmar
Cc: Peter Jones
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
19 May, 2010
1 commit
-
* 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
...
18 May, 2010
1 commit
-
It removes a hack from nouveau code which had to detect which
region to pass to kick vesafb/efifb.Signed-off-by: Marcin Slusarz
Cc: Eric Anholt
Cc: Ben Skeggs
Cc: Thomas Hellstrom
Cc: Dave Airlie
Cc: Peter Jones
Cc: Benjamin Herrenschmidt
Signed-off-by: Dave Airlie
25 Apr, 2010
1 commit
-
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: 0xB0030000The 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:00The 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 statesgpu-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
Acked-by: Peter Jones
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Mar, 2010
1 commit
-
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
Cc: Adrian Bunk
Cc: Alberto Mardegan
Cc: Andrew Morton
Cc: Andriy Skulysh
Cc: Antonino Daplas
Cc: Anton Vorontsov
Cc: Ben Dooks
Cc: Chandramouli Narayanan
Cc: Christoph Hellwig
Cc: Frans Pop
Cc: Geert Uytterhoeven
Cc: Greg Kroah-Hartman
Cc: Helge Deller
Cc: Huang Ying
Cc: Ian Molton
Cc: Joshua Kinard
Cc: Kaj-Michael Lang
Cc: Krzysztof Helt
Cc: linux-fbdev-devel@lists.sourceforge.net
Cc: Maciej W. Rozycki
Cc: Magnus Damm
Cc: Martin Michlmayr
Cc: Matthias Kaehlcke
Cc: Paul Mundt
Cc: Pavel Machek
Cc: Philipp Zabel
Cc: Richard Purdie
Cc: Roel Kluin
Cc: Roland Stigge
Cc: Russell King
Cc: Thomas Bogendoerfer
Cc: Vincent Sanders
Cc: Yoichi Yuasa
Acked-by: Ralf Baechle
Acked-by: Arnaud Patard
Acked-by: James Simmons
Acked-by: Peter Jones
Acked-by: Jaya Kumar
Signed-off-by: Greg Kroah-Hartman
23 Feb, 2010
1 commit
-
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
Reported-by: Alex Zhavnerchik
Tested-by: Alex Zhavnerchik
Acked-by: Peter Jones
Cc: Huang Ying
Cc: Dave Airlie
Cc: "Rafael J. Wysocki"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Jun, 2009
1 commit
-
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
Acked-by: Peter Jones
Cc: Geert Uytterhoeven
Cc: Krzysztof Helt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Apr, 2009
1 commit
-
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
Acked-by: Peter Jones
Cc: Krzysztof Helt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 Apr, 2009
1 commit
-
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
Acked-by: Huang Ying
Cc: Krzysztof Helt
Cc: Chandramouli Narayanan
Acked-by: Peter Jones
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Oct, 2008
1 commit
-
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
Cc: Krzysztof Helt
Cc: Geert Uytterhoeven
Cc: Jaya Kumar
Cc: Ralf Baechle
Cc: Maciej W. Rozycki
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Nov, 2007
1 commit
-
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
Signed-off-by: Huang Ying
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Andi Kleen
Cc: "Antonino A. Daplas"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
