1. 30 8月, 2013 1 次提交
    • P
      Release efifb's colormap in efifb_destroy() · 907355a9
      Peter Jones 提交于
      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: NPeter Jones <pjones@redhat.com>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      907355a9
  2. 04 1月, 2013 1 次提交
    • G
      Drivers: video: remove __dev* attributes. · 48c68c4f
      Greg Kroah-Hartman 提交于
      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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      48c68c4f
  3. 17 9月, 2012 1 次提交
    • M
      efifb: Skip DMI checks if the bootloader knows what it's doing · f462ed93
      Matthew Garrett 提交于
      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: NMatthew Garrett <mjg@redhat.com>
      Acked-by: NPeter Jones <pjones@redhat.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      f462ed93
  4. 24 4月, 2012 2 次提交
  5. 14 6月, 2011 1 次提交
  6. 02 6月, 2011 3 次提交
  7. 24 5月, 2011 1 次提交
  8. 07 4月, 2011 2 次提交
  9. 31 3月, 2011 1 次提交
  10. 23 9月, 2010 2 次提交
  11. 11 8月, 2010 1 次提交
  12. 18 5月, 2010 1 次提交
  13. 25 4月, 2010 1 次提交
    • T
      drivers/video/efifb.c: support framebuffer for NVIDIA 9400M in MacBook Pro 5,1 · 8a3bdfe6
      Thomas Gerlach 提交于
      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: NThomas Gerlach <t.m.gerlach@freenet.de>
      Acked-by: NPeter Jones <pjones@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8a3bdfe6
  14. 08 3月, 2010 1 次提交
    • U
      platform-drivers: move probe to .devinit.text in drivers/video · c2e13037
      Uwe Kleine-König 提交于
      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: NUwe 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: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NArnaud Patard <arnaud.patard@rtp-net.org>
      Acked-by: NJames Simmons <jsimmons@infradead.org>
      Acked-by: NPeter Jones <pjones@redhat.com>
      Acked-by: NJaya Kumar <jayakumar.lkml@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c2e13037
  15. 23 2月, 2010 1 次提交
  16. 17 6月, 2009 1 次提交
    • D
      fbdev: add support for handoff from firmware to hw framebuffers · 4410f391
      Dave Airlie 提交于
      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: NDave Airlie <airlied@redhat.com>
      Acked-by: NPeter Jones <pjones@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4410f391
  17. 14 4月, 2009 1 次提交
  18. 01 4月, 2009 1 次提交
    • B
      efifb: dmi set video type · e14a685d
      Brian Maly 提交于
      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: NBrian Maly <bmaly@redhat.com>
      Acked-by: NHuang Ying <ying.huang@intel.com>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Cc: Chandramouli Narayanan <mouli@linux.intel.com>
      Acked-by: NPeter Jones <pjones@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e14a685d
  19. 17 10月, 2008 1 次提交
  20. 30 11月, 2007 1 次提交
    • H
      x86_64 EFI boot support: EFI frame buffer driver · 7c83172b
      Huang, Ying 提交于
      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: NChandramouli Narayanan <mouli@linux.intel.com>
      Signed-off-by: NHuang 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7c83172b