1. 10 9月, 2009 1 次提交
    • B
      PCI/GPU: implement VGA arbitration on Linux · deb2d2ec
      Benjamin Herrenschmidt 提交于
      Background:
      Graphic devices are accessed through ranges in I/O or memory space. While most
      modern devices allow relocation of such ranges, some "Legacy" VGA devices
      implemented on PCI will typically have the same "hard-decoded" addresses as
      they did on ISA. For more details see "PCI Bus Binding to IEEE Std 1275-1994
      Standard for Boot (Initialization Configuration) Firmware Revision 2.1"
      Section 7, Legacy Devices.
      
      The Resource Access Control (RAC) module inside the X server currently does
      the task of arbitration when more than one legacy device co-exists on the same
      machine. But the problem happens when these devices are trying to be accessed
      by different userspace clients (e.g. two server in parallel). Their address
      assignments conflict. Therefore an arbitration scheme _outside_ of the X
      server is needed to control the sharing of these resources. This document
      introduces the operation of the VGA arbiter implemented for Linux kernel.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NTiago Vignatti <tiago.vignatti@nokia.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      deb2d2ec
  2. 15 7月, 2009 1 次提交
  3. 03 7月, 2009 1 次提交
  4. 20 6月, 2009 1 次提交
  5. 17 6月, 2009 1 次提交
    • J
      mb862xxfb: restrict compliation of platform driver to PPC · 336e747e
      Julian Calaby 提交于
      The OpenFirmware part of this driver is uncompilable on SPARC due to it's
      dependance on several PPC specific functions.
      
      Restricting this to PPC to prevent these build errors:
        CC      drivers/video/mb862xx/mb862xxfb.o
      drivers/video/mb862xx/mb862xxfb.c: In function 'of_platform_mb862xx_probe':
      drivers/video/mb862xx/mb862xxfb.c:559: error: implicit declaration of function 'of_address_to_resource'
      drivers/video/mb862xx/mb862xxfb.c:575: error: 'NO_IRQ' undeclared (first use in this function)
      drivers/video/mb862xx/mb862xxfb.c:575: error: (Each undeclared identifier is reported only once
      drivers/video/mb862xx/mb862xxfb.c:575: error: for each function it appears in.)
      
      This was found using randconfig builds.
      Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
      Signed-off-by: NAnatolij Gustschin <agust@denx.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Anatolij Gustschin <agust@denx.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      336e747e
  6. 13 6月, 2009 1 次提交
  7. 21 5月, 2009 1 次提交
  8. 13 5月, 2009 1 次提交
  9. 07 5月, 2009 1 次提交
  10. 07 4月, 2009 1 次提交
  11. 01 4月, 2009 3 次提交
  12. 13 3月, 2009 1 次提交
  13. 27 2月, 2009 2 次提交
  14. 19 2月, 2009 1 次提交
  15. 10 2月, 2009 1 次提交
  16. 08 2月, 2009 1 次提交
    • I
      drm/i915: select framebuffer support automatically · d2f59357
      Ingo Molnar 提交于
      Migration helper.
      
      The i915 driver recently added a 'depends on FB' rule to its
      Kconfig entry - which silently turns off DRM_I915 if someone
      has a working config but no CONFIG_FB selected, and upgrades
      to the latest upstream kernel.
      
      Norbert Preining reported this problem:
      
         Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=12599
         Subject     : dri /dev node disappeared with 2.6.29-rc1
      
      So change it to "select FB", which auto-selects framebuffer
      support. This way the driver keeps working, regardless of
      whether FB was enabled before or not.
      
      Kconfig select's of interactive options can be problematic to
      dependencies and can cause build breakages - but in this case
      it's safe because it's a leaf entry with no dependencies of its
      own.
      
      ( There is some minor circular dependency fallout as FB_I810
        and FB_INTEL also used 'depends on FB' constructs - update
        those to "select FB" too. )
      Reported-by: NNorbert Preining <preining@logic.at>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      d2f59357
  17. 30 1月, 2009 1 次提交
  18. 22 1月, 2009 1 次提交
  19. 29 12月, 2008 1 次提交
    • E
      [ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices · 198fc108
      Eric Miao 提交于
      PXA27x and later processors support overlay1 and overlay2 on-top of the
      base framebuffer (although under-neath the base is also possible). They
      support palette and no-palette RGB formats, as well as YUV formats (only
      available on overlay2). These overlays have dedicated DMA channels and
      behave in a similar way as a framebuffer.
      
      This heavily simplified and re-structured work is based on the original
      pxafb_overlay.c (which is pending for mainline merge for a long time).
      
      The major problems with this pxafb_overlay.c are (if you are interested
      in the history):
      
        1. heavily redundant (the control logics for overlay1 and overlay2 are
           actually identical except for some small operations,  which are now
           abstracted into a 'pxafb_layer_ops' structure)
      
        2. a lot of useless and un-tested code (two workarounds which are now
           fixed on mature silicons)
      
        3. cursorfb is actually useless, hardware cursor should not be used
           this way, and the code was actually un-tested for a long time.
      
      The code in this patch should be self-explanatory, I tried to add minimum
      comments. As said, this is basically simplified, there are several things
      still on the pending list:
      
        1. palette mode is un-supported and un-tested (although re-using the
           palette code of the base framebuffer is actually very easy now with
           previous clean-up patches)
      
        2. fb_pan_display for overlay(s) is un-supported
      
        3. the base framebuffer can actually be abstracted by 'pxafb_layer' as
           well, which will help further re-use of the code and keep a better
           and consistent structure. (This is the reason I named it 'pxafb_layer'
           instead of 'pxafb_overlay' or something alike)
      
      See Documentation/fb/pxafb.txt for additional usage information.
      Signed-off-by: NEric Miao <eric.miao@marvell.com>
      Cc: Rodolfo Giometti <giometti@linux.it>
      Signed-off-by: NEric Miao <ycmiao@ycmiao-hp520.(none)>
      198fc108
  20. 22 12月, 2008 3 次提交
    • M
      video: sh_mobile_lcdcfb deferred io support · 8564557a
      Magnus Damm 提交于
      This patch adds sh_mobile_lcdcfb deferred io support for SYS panels.
      
      The LCDC hardware block managed by the sh_mobile_lcdcfb driver supports
      RGB or SYS panel configurations. SYS panels come with an external display
      controller that is resposible for refreshing the actual LCD panel. RGB
      panels are controlled directly by the LCDC and they need to be refreshed
      by the LCDC hardware.
      
      In the case of SYS panels we can save some power by configuring the LCDC
      hardware block in one-shot mode. In this one-shot mode panel refresh is
      managed by software. This works well together with deferred io since it
      allows us to stop clocks for most of the time and only enable clocks when
      we actually want to trigger an update. When there is no fbdev activity
      the clocks are kept stopped which allows us to deep sleep.
      
      The refresh rate in deferred io mode is set using platform data. The same
      platform data can also be used to disable deferred io mode.
      
      As with other deferred io frame buffers user space code should use fsync()
      on the frame buffer device to trigger an update.
      Signed-off-by: NMagnus Damm <damm@igel.co.jp>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      8564557a
    • M
      sh_mobile_lcdc: use FB_SYS helpers instead of FB_CFB · 2540c111
      Magnus Damm 提交于
      Since the sh_mobile_lcdc hardware has the framebuffer(s) in system RAM,
      use FB_SYS instead of FB_CFB. Also hook in read and write helpers.
      Signed-off-by: NMagnus Damm <damm@igel.co.jp>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      2540c111
    • N
      sh: sh7760fb: Add support SH7720/SH7721 of Renesas · 5c72f303
      Nobuhiro Iwamatsu 提交于
      SH7720 and 7721 has IP of Frame Buffer same as SH7760.
      This driver can support these.
      Signed-off-by: NNobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      5c72f303
  21. 27 11月, 2008 1 次提交
  22. 07 11月, 2008 1 次提交
  23. 17 10月, 2008 5 次提交
  24. 04 9月, 2008 1 次提交
  25. 27 8月, 2008 2 次提交
  26. 25 7月, 2008 4 次提交
  27. 14 7月, 2008 1 次提交
    • D
      drm: reorganise drm tree to be more future proof. · c0e09200
      Dave Airlie 提交于
      With the coming of kernel based modesetting and the memory manager stuff,
      the everything in one directory approach was getting very ugly and
      starting to be unmanageable.
      
      This restructures the drm along the lines of other kernel components.
      
      It creates a drivers/gpu/drm directory and moves the hw drivers into
      subdirectores. It moves the includes into an include/drm, and
      sets up the unifdef for the userspace headers we should be exporting.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      c0e09200