linux-toradex.git/drivers/video/modedb.c, branch v2.6.34.8

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

2010-03-30T13:02:32+00:00

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo 
Guess-its-ok-by: Christoph Lameter 
Cc: Ingo Molnar 
Cc: Lee Schermerhorn

video: fix first line of kernel-doc for a few functions

2010-03-12T23:52:34+00:00

The function name must be followed by a space, hypen, space, and a short
description.

Signed-off-by: Ben Hutchings 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fbdev: drop custom atoi from drivers/video/modedb.c

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

Kernel has simple_strtol() implementation which could be used as atoi().

Signed-off-by: Andy Shevchenko 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fbdev: add video modes for resolutions and timings of PAL RGB

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

This patch was taken from vga-sync-field version 0.0.3 [1][2].

[1] http://lowbyte.de/vga-sync-fields/vga-sync-fields-0.0.3.tgz
[2] http://git.hellersdorfer-jugendchor.de/?p=3Dvga2scart.git;a=3Dcommit;h=
=3Dc5c8ed6c51fc9879dbf38d8b91d5db6f4300ea03

Signed-off-by: Thomas Hilber 
Signed-off-by: Paul Menzel 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fbdev: fix typo in drivers/video/modedb.c

2009-01-06T23:59:26+00:00

When I viewed drivers/video/modedb.c, I noticed a very old typo already
contained in 2.6.0.

This typo remained unheeded at least 5 years.  Clear evidence of its
importance.  ;)

Acked-by: Geert Uytterhoeven 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fbdev: export symbol fb_mode_option

2008-06-06T18:29:12+00:00

Frame buffer and mode setting drivers can be built as modules,
so fb_mode_option needs to be exported to support these.

Prevents this error:

  ERROR: "fb_mode_option" [drivers/ps3/ps3av_mod.ko] undefined!

Signed-off-by: Geoff Levand 
Acked-by: Geert Uytterhoeven 
Cc: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

modedb: fix incorrect sync and vmode flags for CVT modes

2008-06-06T18:29:09+00:00

The temporary structure for calculated CVT mode is not initialized.  Few
fields have only bits or-ed or and-ed so they may be left in incorrect
(random) state.

Testing of the tridentfb seems like a good exercise for the fbdev layer.

Signed-off-by: Krzysztof Helt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

video: replace remaining FUNCTION occurrences

2008-04-28T15:58:42+00:00

__FUNCTION__ is gcc-specific, use __func__

Signed-off-by: Harvey Harrison 
Cc: "Antonino A. Daplas" 
Cc: Krzysztof Helt 
Cc: Antonino Daplas 
Cc: Antonino A. Daplas 
Cc: Antonino Daplas 
Cc: Richard Purdie 
Cc: Jean Delvare 
Cc: Adrian Bunk 
Cc: Russell King 
Cc: Benjamin Herrenschmidt 
Cc: Ben Dooks 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fbdev: make the best-fit section of fb_find_mode return the closest matching mode

2008-04-28T15:58:35+00:00

Currently, if a perfect match in terms of resolution is not found,
fb_find_mode() only looks for a best-fit mode among modes with a higher
resolution than the one requested.  Thus, if the user requests a resolution
higher than the largest supported one, they are dropped to the default mode
(usually a low resolution one).

Change this behaviour so that all valid video modes are considered when
looking for a best-fit mode, while still preferring modes with a higher
resolution.

Signed-off-by: Michal Januszewski 
Cc: Krzysztof Helt 
Cc: "Antonino A. Daplas" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fix radeonfb regression with Xpress 200m 5955

2008-01-17T23:38:59+00:00

Fix http://bugzilla.kernel.org/show_bug.cgi?id=9762

Framebuffer is ok only with default parameters only (it is 1280x800-8@60).  If
parameters are video=radeonfb:1280x800-32@60 then xres, yres and xres_virtual
are ok but yres_virtual is 1024.  It can be corrected by fbset utility so I
think it can be corrected in the driver code also.

Steps to reproduce: video=radeonfb:1280x800-32@60 or
video=radeonfb:1280x800-16@60

Add 1280x800 mode into modedb

Cc: "Rafael J. Wysocki" 
Cc: "Antonino A. Daplas" 
Cc: Geert Uytterhoeven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds