Skip to content

L
linux-davinci
An error occurred fetching the project authors.
Switch branch/tag
  1. 16 Mar, 2010 1 commit
  3. 14 Mar, 2010 1 commit
  5. 16 Dec, 2009 1 commit
  7. 10 Dec, 2009 1 commit
  9. 09 Dec, 2009 1 commit
    • Tomi Valkeinen's avatar
      OMAP: Add VRAM manager · afedec18
      Tomi Valkeinen authored 
      Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:

- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations

The upcoming DSS2 uses VRAM manager.

VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.
Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@nokia.com>
      afedec18
  11. 16 Nov, 2009 1 commit
  13. 12 Nov, 2009 1 commit
  15. 08 Oct, 2009 1 commit
  17. 23 Sep, 2009 4 commits
    • Jean Delvare's avatar
      matroxfb: make CONFIG_FB_MATROX_MULTIHEAD=y mandatory · 0728bacb
      Jean Delvare authored 
      I would like to get rid of option CONFIG_FB_MATROX_MULTIHEAD and just
always enable it.  There are many reasons for doing this:

* CONFIG_FB_MATROX_MULTIHEAD=y is what all x86 distributions do, so it
  definitely works or we would know by now.

* Building the matroxfb driver with CONFIG_FB_MATROX_MULTIHEAD not set
  results in the following build warning:

drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_open':
drivers/video/matrox/matroxfb_crtc2.c:265: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true'
drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_release':
drivers/video/matrox/matroxfb_crtc2.c:285: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true'

This is nothing to be worried about, the driver will work fine, but build
warnings are still annoying.

* The trick to get multihead support without CONFIG_FB_MATROX_MULTIHEAD,
  which is described in the config help text, no longer works: you can't
  load the same kernel module more than once.

* I fail to see how CONFIG_FB_MATROX_MULTIHEAD=y would make the code
  significantly slower, contrary to what the help text says.  A few extra
  parameters on the stack here and there can't really slow things down in
  comaprison to the rest of the code, and register access.

* The driver built without CONFIG_FB_MATROX_MULTIHEAD is larger than the
  driver build with CONFIG_FB_MATROX_MULTIHEAD=y by 8%.

* One less configuration option makes things simpler.  We add options
  all the time, being able to remove one for once is nice.  It improves
  testing coverage.  And I don't think the Matrox adapters are still
  popular enough to warrant overdetailed configuration settings.

* We should be able to unobfuscate the driver code quite a bit after
  this change (patches follow.)
Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
Acked-by: default avatarPetr Vandrovec <vandrove@vc.cvut.cz>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0728bacb
    • Ryan Mallon's avatar
      ep93xx video driver · 88017bda
      Ryan Mallon authored 
      EP93xx video driver plus documentation.
Signed-off-by: default avatarRyan Mallon <ryan@bluewatersys.com>
Acked-by: default avatarH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Daniele Venzano <linux@brownhat.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      88017bda
    • Sudhakar Rajashekhara's avatar
      davinci: fb: Frame Buffer driver for TI DA8xx/OMAP-L1xx · 4ed824d9
      Sudhakar Rajashekhara authored 
      Add LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture.
LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a.

LCDC on DA8xx consists of two independent controllers, the Raster
Controller and the LCD Interface Display Driver (LIDD) controller.  LIDD
further supports character and graphic displays.

This patch adds support for the graphic display (Sharp LQ035Q3DG01) found
on the DA830 based EVM.  The EVM details can be found at:
http://support.spectrumdigital.com/boards/dskda830/revc/.
Signed-off-by: default avatarSudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: default avatarPavel Kiryukhin <pkiryukhin@ru.mvista.com>
Signed-off-by: default avatarSteve Chen <schen@mvista.com>
Acked-by: default avatarKrzysztof Helt <krzysztof.h1@wp.pl>
DESC
davinci-fb-frame-buffer-driver-for-ti-da8xx-omap-l1xx-fix
EDESC
From: Andrew Morton <akpm@linux-foundation.org>

fix kconfig indenting

Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Pavel Kiryukhin <pkiryukhin@ru.mvista.com>
Cc: Steve Chen <schen@mvista.com>
Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4ed824d9
    • Pavel Machek's avatar
      fbdev: framebuffer support for HTC Dream · d480ace0
      Pavel Machek authored 
      Add a framebuffer driver for Qualcomm MSM/QSD SoCs, tested on HTC Dream
smartphone (aka T-Mobile G1, aka ADP1).

Brian said:

  I did the original quick and dirty version for bringup.  Rebecca took
  over and (re)wrote the bulk of the driver, getting things stable for
  production ship of Dream and Sapphire, and Dima is currently adding
  support for later Qualcomm chipsets (QSD8x50, etc).
Signed-off-by: default avatarPavel Machek <pavel@ucw.cz>
Cc: Brian Swetland <swetland@google.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Rebecca Schultz Zavin <rebecca@android.com>
Cc: Dima Zavin <dima@android.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d480ace0
  19. 09 Sep, 2009 1 commit
    • Benjamin Herrenschmidt's avatar
      PCI/GPU: implement VGA arbitration on Linux · deb2d2ec
      Benjamin Herrenschmidt authored 
      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: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: default avatarTiago Vignatti <tiago.vignatti@nokia.com>
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      deb2d2ec
  21. 23 Jul, 2009 1 commit
  23. 15 Jul, 2009 1 commit
  25. 07 Jul, 2009 1 commit
    • Paul Mundt's avatar
      video: sh_mobile_lcdcfb: depends on HAVE_CLK. · 727dc3fd
      Paul Mundt authored 
      This deifdefs the driver and adds an explicit HAVE_CLK dependency. Given
that all SH platforms provide it, there is no reason to keep this as an
ifdef. Other architectures that implement support for this driver will
already have to provide clock framework support for timers and so on
already, so adding this as an additional dependency is not terribly
probematic.
Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      727dc3fd
  27. 03 Jul, 2009 1 commit
  29. 27 Jun, 2009 1 commit
  31. 19 Jun, 2009 1 commit
  33. 17 Jun, 2009 1 commit
    • Julian Calaby's avatar
      mb862xxfb: restrict compliation of platform driver to PPC · 336e747e
      Julian Calaby authored 
      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: default avatarJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: default avatarAnatolij 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: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      336e747e
  35. 12 Jun, 2009 1 commit
  37. 21 May, 2009 1 commit
  39. 12 May, 2009 1 commit
  41. 07 May, 2009 1 commit
  43. 07 Apr, 2009 1 commit
  45. 01 Apr, 2009 3 commits
  47. 13 Mar, 2009 1 commit
  49. 26 Feb, 2009 2 commits
  51. 18 Feb, 2009 1 commit
  53. 10 Feb, 2009 1 commit
  55. 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
  57. 30 Jan, 2009 1 commit
  59. 21 Jan, 2009 1 commit
  61. 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
  63. 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