linux-toradex.git/Documentation/fb, branch v2.6.33.19

viafb: documentation update

2009-12-16T15:20:05+00:00

We now support the VX855, and the VX800 is no longer unaccellerated.
viafb_video_dev was removed as it was useless.

Signed-off-by: Harald Welte 
Signed-off-by: Florian Tobias Schandinat 
Cc: Joseph Chan 
Cc: Scott Fang 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fbdev: Migrate mailing lists to vger

2009-11-30T21:46:04+00:00

The fbdev mailing lists at SourceForge have been migrated to a single
mailing list at kernel.org: linux-fbdev@vger.kernel.org.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Jean Delvare 
Signed-off-by: Linus Torvalds

matroxfb: make CONFIG_FB_MATROX_MULTIHEAD=y mandatory

2009-09-23T14:39:56+00:00

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: Jean Delvare 
Acked-by: Petr Vandrovec 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ep93xx video driver

2009-09-23T14:39:51+00:00

EP93xx video driver plus documentation.

Signed-off-by: Ryan Mallon 
Acked-by: H Hartley Sweeten 
Cc: Daniele Venzano 
Cc: Russell King 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Documentation/fb/vesafb.txt: fix typo

2009-06-17T02:47:58+00:00

Signed-off-by: Paul Menzel 
Cc: Gerd Knorr 
Cc: Nico Schmoigl 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

trivial: Miscellaneous documentation typo fixes

2009-06-12T16:01:47+00:00

Fix various typos in documentation txts.

Signed-off-by: Matt LaPlante 
Signed-off-by: Jiri Kosina

uvesafb: documentation update

2009-04-07T15:31:09+00:00

Update the uvesafb documentation to accurately reflect the default options
used by the driver.

Signed-off-by: Michal Januszewski 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fbdev: remove cyblafb driver

2009-04-01T15:59:33+00:00

A tridentfb driver has all the functionality of the cyblafb driver without
the bugs of the latter.

Changes to the tridentfb driver:

- FBINFO_READS_FAST added to the tridentfb.  The cyblafb used a blitter
  for scrolling which is faster than color expansion on Cyberblade
  chipsets.  The blitter is slower on a discrete Blade3D core.  Use the
  blitter for scrolling in the tridentfb only for integrated Blade3D
  cores.  Now, scrolling speed is about equal for the tridentfb and the
  cyblafb.

- a copyright notice addition is done on request of Jani Monoses (the
  first author of the tridentfb).

Tested on AGP Blade3D card and PCChips
M787CLR motherboard: VIA C3 cpu +
VT8601 north  bridge (aka Cyberblade/i1).

Signed-off-by: Krzysztof Helt 
Cc: "Jani Monoses" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[ARM] pxafb: add support for overlay1 and overlay2 as framebuffer devices

2008-12-29T10:00:04+00:00

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: Eric Miao 
Cc: Rodolfo Giometti 
Signed-off-by: Eric Miao

[ARM] pxafb: allow video memory size to be configurable

2008-12-29T09:59:16+00:00

The amount of video memory size is decided according to the following
order:

1.  x  x  by default, which is the backward
   compatible way

2. size specified in platform data

3. size specified in module parameter 'options' string or specified in
   kernel boot command line (see updated Documentation/fb/pxafb.txt)

And now since the memory is allocated from system memory, the pxafb_mmap
can be removed and the default fb_mmap() should be working all right.

Also, since we now have introduced the 'struct pxafb_dma_buff' for DMA
descriptors and palettes, the allocation can be separated cleanly.

NOTE: the LCD DMA actually supports chained transfer (i.e. page-based
transfers), to simplify the logic and keep the performance (with less
TLB misses when accessing from memory mapped user space), the memory
is allocated by alloc_pages_*() to ensures it's physical contiguous.

Signed-off-by: Eric Miao 
Signed-off-by: Eric Miao