linux-toradex.git/drivers/video/Makefile, branch v3.13.4

drivers/video: implement a simple framebuffer driver

2013-05-24T23:22:51+00:00

A simple frame-buffer describes a raw memory region that may be rendered
to, with the assumption that the display hardware has already been set
up to scan out from that buffer.

This is useful in cases where a bootloader exists and has set up the
display hardware, but a Linux driver doesn't yet exist for the display
hardware.

Examples use-cases include:

* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
  devices, and likely many other ARM or embedded systems.  These cannot
  yet be supported using a full graphics driver, since the panel control
  should be provided by the CDF (Common Display Framework), which has been
  stuck in design/review for quite some time.  One could support these
  panels using custom SoC-specific code, but there is a desire to use
  common infra-structure rather than having each SoC vendor invent their
  own code, hence the desire to wait for CDF.

* Hardware for which a full graphics driver is not yet available, and
  the path to obtain one upstream isn't yet clear.  For example, the
  Raspberry Pi.

* Any hardware in early stages of upstreaming, before a full graphics
  driver has been tackled.  This driver can provide a graphical boot
  console (even full X support) much earlier in the upstreaming process,
  thus making new SoC or board support more generally useful earlier.

[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: Stephen Warren 
Cc: Arnd Bergmann 
Acked-by: Olof Johansson 
Cc: Rob Clark 
Cc: Florian Tobias Schandinat 
Cc: Tomasz Figa 
Cc: Laurent Pinchart 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

drivers/video: add Hyper-V Synthetic Video Frame Buffer Driver

2013-04-29T22:54:26+00:00

This is the driver for the Hyper-V Synthetic Video, which supports
screen resolution up to Full HD 1920x1080 on Windows Server 2012 host,
and 1600x1200 on Windows Server 2008 R2 or earlier.  It also solves the
double mouse cursor issue of the emulated video mode.

Signed-off-by: Haiyang Zhang 
Reviewed-by: K. Y. Srinivasan 
Cc: Greg Kroah-Hartman ,
Cc: Olaf Hering 
Cc: Geert Uytterhoeven 
Cc: Florian Tobias Schandinat 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

videomode: simplify videomode Kconfig and Makefile

2013-03-12T13:46:41+00:00

This patch simplifies videomode related Kconfig and Makefile. After this
patch, there's only one non-user selectable Kconfig option left,
VIDEOMODE_HELPERS. The reasons for the change:

* Videomode helper functions are not something that should be shown in
  the kernel configuration options. The related code should just be
  included if it's needed, i.e. selected by drivers using videomode.

* There's no need to have separate Kconfig options for videomode and
  display_timing. First of all, the amount of code for both is quite
  small. Second, videomode depends on display_timing, and display_timing
  in itself is not really useful, so both would be included in any case.

* CONFIG_VIDEOMODE is a bit vague name, and CONFIG_VIDEOMODE_HELPERS
  describes better what's included.

Signed-off-by: Tomi Valkeinen 
Cc: Steffen Trumtrar 
Acked-by: Laurent Pinchart

Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux

2013-02-26T00:46:44+00:00

Pull drm merge from Dave Airlie:
 "Highlights:

   - TI LCD controller KMS driver

   - TI OMAP KMS driver merged from staging

   - drop gma500 stub driver

   - the fbcon locking fixes

   - the vgacon dirty like zebra fix.

   - open firmware videomode and hdmi common code helpers

   - major locking rework for kms object handling - pageflip/cursor
     won't block on polling anymore!

   - fbcon helper and prime helper cleanups

   - i915: all over the map, haswell power well enhancements, valleyview
     macro horrors cleaned up, killing lots of legacy GTT code,

   - radeon: CS ioctl unification, deprecated UMS support, gpu reset
     rework, VM fixes

   - nouveau: reworked thermal code, external dp/tmds encoder support
     (anx9805), fences sleep instead of polling,

   - exynos: all over the driver fixes."

Lovely conflict in radeon/evergreen_cs.c between commit de0babd60d8d
("drm/radeon: enforce use of radeon_get_ib_value when reading user cmd")
and the new changes that modified that evergreen_dma_cs_parse()
function.

* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (508 commits)
  drm/tilcdc: only build on arm
  drm/i915: Revert hdmi HDP pin checks
  drm/tegra: Add list of framebuffers to debugfs
  drm/tegra: Fix color expansion
  drm/tegra: Split DC_CMD_STATE_CONTROL register write
  drm/tegra: Implement page-flipping support
  drm/tegra: Implement VBLANK support
  drm/tegra: Implement .mode_set_base()
  drm/tegra: Add plane support
  drm/tegra: Remove bogus tegra_framebuffer structure
  drm: Add consistency check for page-flipping
  drm/radeon: Use generic HDMI infoframe helpers
  drm/tegra: Use generic HDMI infoframe helpers
  drm: Add EDID helper documentation
  drm: Add HDMI infoframe helpers
  video: Add generic HDMI infoframe helpers
  drm: Add some missing forward declarations
  drm: Move mode tables to drm_edid.c
  drm: Remove duplicate drm_mode_cea_vic()
  gma500: Fix n, m1 and m2 clock limits for sdvo and lvds
  ...

video: Add generic HDMI infoframe helpers

2013-02-22T07:20:05+00:00

Add generic helpers to pack HDMI infoframes into binary buffers.

Signed-off-by: Thierry Reding 
Reviewed-by: Alex Deucher

video: mmp display subsystem

2013-02-22T01:22:17+00:00

Add mmp display subsystem to support Marvell MMP display controllers.

This subsystem contains 4 parts:
--fb folder
--core.c
--hw folder
--panel folder

1. fb folder contains implementation of fb.  fb get path and overlay
   from common interface and operates on these structures.

2. core.c provides common interface for a hardware abstraction.  Major
   parts of this interface are:

   a) Path: path is a output device connected to a panel or HDMI TV.  Main
      operations of the path is set/get timing/output color.  fb operates
      output device through path structure.

   b) Ovly: Ovly is a buffer shown on the path.

      Ovly describes frame buffer and its source/destination size, offset,
      input color, buffer address, z-order, and so on.  Each fb device maps
      to one overlay.

3. hw folder contains implementation of hardware operations defined by
   core.c.  It registers paths for fb use.

4. panel folder contains implementation of panels.  It's connected to
   path.  Panel drivers would also regiester panels and linked to path
   when probe.

Signed-off-by: Zhou Zhu 
Signed-off-by: Lisa Du 
Cc: Guoqing Li 
Acked-by: Haojian Zhuang 
Cc: Florian Tobias Schandinat 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

goldfish: framebuffer driver

2013-02-22T01:22:17+00:00

Framebuffer support for the Goldfish emulator.  This takes the Google
emulator and applies the x86 cleanups as well as moving the blank
methods to the usual Linux place and dropping the Android early suspend
logic (for now at least, that can be looked at as Android and upstream
converge).  Dropped various oddities like setting MTRRs on a virtual
frame buffer emulation...

With the drivers so far you can now boot a Linux initrd and have fun.

[sheng@linux.intel.com: cleaned up to handle x86]
[thomas.keel@intel.com: ported to 3.4]
[alan@linux.intel.com: cleaned up for style and 3.7, moved blank methods]
[akpm@linux-foundation.org: fix (silly) sparse warnings]
Signed-off-by: Mike A. Chan 
Signed-off-by: Arve Hjønnevåg 
Signed-off-by: Sheng Yang 
Signed-off-by: Yunhong Jiang 
Signed-off-by: Xiaohui Xin 
Signed-off-by: Jun Nakajima 
Signed-off-by: Bruce Beare 
Signed-off-by: Tom Keel 
Signed-off-by: Alan Cox 
Cc: Florian Tobias Schandinat 
Cc: Tomi Valkeinen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

video: add of helper for display timings/videomode

2013-01-24T08:03:48+00:00

This adds support for reading display timings from DT into a struct
display_timings. The of_display_timing implementation supports multiple
subnodes. All children are read into an array, that can be queried.

If no native mode is specified, the first subnode will be used.

For cases where the graphics driver knows there can be only one
mode description or where the driver only supports one mode, a helper
function of_get_videomode is added, that gets a struct videomode from DT.

Signed-off-by: Steffen Trumtrar 
Signed-off-by: Philipp Zabel 
Acked-by: Stephen Warren 
Reviewed-by: Thierry Reding 
Acked-by: Thierry Reding 
Tested-by: Thierry Reding 
Tested-by: Philipp Zabel 
Reviewed-by: Laurent Pinchart 
Acked-by: Laurent Pinchart 
Tested-by: Afzal Mohammed 
Tested-by: Rob Clark 
Tested-by: Leela Krishna Amudala

video: add display_timing and videomode

2013-01-24T08:03:04+00:00

Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.

Also, add helper functions to convert from display timings to a generic videomode
structure.

The struct display_timing specifies all needed parameters to describe the signal
properties of a display in one mode. This includes
    - ranges for signals that may have min-, max- and typical values
    - single integers for signals that can be on, off or are ignored
    - booleans for signals that are either on or off

As a display may support multiple modes like this, a struct display_timings is
added, that holds all given struct display_timing pointers and declares the
native mode of the display.

Although a display may state that a signal can be in a range, it is driven with
fixed values that indicate a videomode. Therefore graphic drivers don't need all
the information of struct display_timing, but would generate a videomode from
the given set of supported signal timings and work with that.

The video subsystems all define their own structs that describe a mode and work
with that (e.g. fb_videomode or drm_display_mode). To slowly replace all those
various structures and allow code reuse across those subsystems, add struct
videomode as a generic description.

This patch only includes the most basic fields in struct videomode. All missing
fields that are needed to have a really generic video mode description can be
added at a later stage.

Signed-off-by: Steffen Trumtrar 
Reviewed-by: Thierry Reding 
Acked-by: Thierry Reding 
Tested-by: Thierry Reding 
Tested-by: Philipp Zabel 
Reviewed-by: Laurent Pinchart 
Acked-by: Laurent Pinchart 
Tested-by: Afzal Mohammed 
Tested-by: Rob Clark 
Tested-by: Leela Krishna Amudala

drivers/video: add support for the Solomon SSD1307 OLED Controller

2012-12-10T09:33:53+00:00

Add support for the Solomon SSD1307 OLED controller found on the
Crystalfontz CFA10036 board.

This controller can drive a display with a resolution up to 128x39 and can
operate over I2C or SPI.

The current driver has only been tested on the CFA-10036, that is using
this controller over I2C to driver a 96x16 OLED screen.

[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Maxime Ripard 
Cc: Brian Lilly 
Cc: Greg KH 
Cc: Florian Tobias Schandinat 
Cc: Thomas Petazzoni 
Cc: Tomi Valkeinen 
Signed-off-by: Andrew Morton 
Signed-off-by: Tomi Valkeinen