Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 12 Jun, 2009 1 commit
  3. 12 May, 2009 1 commit
  5. 07 May, 2009 1 commit
  7. 07 Apr, 2009 1 commit
  9. 01 Apr, 2009 3 commits
  11. 13 Mar, 2009 1 commit
  13. 26 Feb, 2009 2 commits
  15. 18 Feb, 2009 1 commit
  17. 10 Feb, 2009 1 commit
  19. 08 Feb, 2009 1 commit
    • Ingo Molnar's avatar
      drm/i915: select framebuffer support automatically · d2f59357
      Ingo Molnar authored 
      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: default avatarNorbert Preining <preining@logic.at>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarDave Airlie <airlied@linux.ie>
      d2f59357
  21. 30 Jan, 2009 1 commit
  23. 21 Jan, 2009 1 commit
  25. 29 Dec, 2008 1 commit
    • Eric Miao's avatar
      [ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices · 198fc108
      Eric Miao authored 
      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: default avatarEric Miao <eric.miao@marvell.com>
Cc: Rodolfo Giometti <giometti@linux.it>
Signed-off-by: default avatarEric Miao <ycmiao@ycmiao-hp520.(none)>
      198fc108
  27. 22 Dec, 2008 3 commits
    • Magnus Damm's avatar
      video: sh_mobile_lcdcfb deferred io support · 8564557a
      Magnus Damm authored 
      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: default avatarMagnus Damm <damm@igel.co.jp>
Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      8564557a
    • Magnus Damm's avatar
      sh_mobile_lcdc: use FB_SYS helpers instead of FB_CFB · 2540c111
      Magnus Damm authored 
      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: default avatarMagnus Damm <damm@igel.co.jp>
Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      2540c111
    • Nobuhiro Iwamatsu's avatar
      sh: sh7760fb: Add support SH7720/SH7721 of Renesas · 5c72f303
      Nobuhiro Iwamatsu authored 
      SH7720 and 7721 has IP of Frame Buffer same as SH7760.
This driver can support these.
Signed-off-by: default avatarNobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      5c72f303
  29. 27 Nov, 2008 1 commit
  31. 06 Nov, 2008 1 commit
  33. 16 Oct, 2008 5 commits
  35. 03 Sep, 2008 1 commit
  37. 26 Aug, 2008 2 commits
  39. 24 Jul, 2008 4 commits
  41. 14 Jul, 2008 1 commit
    • Dave Airlie's avatar
      drm: reorganise drm tree to be more future proof. · c0e09200
      Dave Airlie authored 
      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: default avatarDave Airlie <airlied@redhat.com>
      c0e09200
  43. 04 Jul, 2008 1 commit
  45. 18 May, 2008 2 commits
  47. 13 May, 2008 1 commit
  49. 30 Apr, 2008 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7