linux.git/drivers/staging/udlfb, branch v2.6.34 Linux kernel source tree 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 Tejun Heo tj@kernel.org 2010-03-24T08:04:11+00:00 5a0e3ad6af8660be21ca98a971cd00f331318c05 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 <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com> 
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 <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Staging: udlfb: remove printk and small cleanup 2010-03-04T00:43:00+00:00 Bernie Thompson bernie@plugable.com 2010-02-15T14:46:48+00:00 bd80816b2877879d36011815858c8681408cc625 Remove last remaining printk and clarify comments Signed-off-by: Bernie Thompson <bernie@plugable.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Remove last remaining printk and clarify comments

Signed-off-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: udlfb: explicit dependencies and warnings 2010-03-04T00:43:00+00:00 Bernie Thompson bernie@plugable.com 2010-02-15T14:46:35+00:00 dd8015f1c83bfde9966c86a5958abd466a304398 Specify Kconfig dependencies, and include warnings for building as a module udlfb is dependent on FB_DEFERRED_IO, FB_SYS_*, and FB_MODE_HELPERS Because many kernels do not include defio (which cannot be built as a module), yet users want to be able to build udlfb as a module later, udlfb has ifdefs and these dependency warnings to help udlfb build with or without certain dependencies, but also print warnings for any lost function. Even though this kind of flexibility isn't common, we've gotten feedback from a significant portion of users that they were frustrated without it. Signed-off-by: Bernie Thompson <bernie@plugable.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Specify Kconfig dependencies, and include warnings for building as a module

udlfb is dependent on FB_DEFERRED_IO, FB_SYS_*, and FB_MODE_HELPERS

Because many kernels do not include defio (which cannot be built
as a module), yet users want to be able to build udlfb as a module later,
udlfb has ifdefs and these dependency warnings to help udlfb build with or
without certain dependencies, but also print warnings for any lost function.

Even though this kind of flexibility isn't common, we've gotten feedback
from a significant portion of users that they were frustrated without it.

Signed-off-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: udlfb: Support for fbdev mmap clients (defio) 2010-03-04T00:43:00+00:00 Bernie Thompson bernie@plugable.com 2010-02-15T14:46:26+00:00 3e8f3d6fa672896096068296658a769649186150 Add support for fbdev mmap clients who don't send damage ioctls Because DisplayLink devices are out on the other end of usb, their "framebuffer" is just normal system memory. So memory mapped writes don't automatically trigger anything. So up to this point, standard fbdev clients who rely on mmap() will get an unchanging screen. This patch makes udlfb a client of Jaya Kumar's defio framework - which sets up page fault triggers, and those faults are accumulated and sent to udlfb on a defferred basis, to process as damage notifications for the framebuffer. Because this involves more overhead than a notification directly from the application (e.g. just passing on X DAMAGE extension notifications), a sysfs attribute is provided by udlfb to control defio support. /sys/class/graphics/fb*/use_defio - writing a "0" to this file before calling mmap() causes defio to not be initialized - instead udlfb will rely on getting damage notifications directly through the damage ioctl. There are unsolved rendering problems with defio (horizontal dead regions on framebuffer, that accumulate over time) which still needs a fix. Signed-off-by: Bernie Thompson <bernie@plugable.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Add support for fbdev mmap clients who don't send damage ioctls

Because DisplayLink devices are out on the other end of usb, their
"framebuffer" is just normal system memory. So memory mapped writes
don't automatically trigger anything. So up to this point, standard
fbdev clients who rely on mmap() will get an unchanging screen.

This patch makes udlfb a client of Jaya Kumar's defio framework - which sets
up page fault triggers, and those faults are accumulated and sent to udlfb
on a defferred basis, to process as damage notifications for the framebuffer.

Because this involves more overhead than a notification directly from
the application (e.g. just passing on X DAMAGE extension notifications),
a sysfs attribute is provided by udlfb to control defio support.

/sys/class/graphics/fb*/use_defio - writing a "0" to this file before
calling mmap() causes defio to not be initialized - instead udlfb
will rely on getting damage notifications directly through the damage ioctl.

There are unsolved rendering problems with defio (horizontal dead regions
on framebuffer, that accumulate over time) which still needs a fix.

Signed-off-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: udlfb: improved rendering performance 2010-03-04T00:43:00+00:00 Bernie Thompson bernie@plugable.com 2010-02-15T14:46:21+00:00 530f43a8a69d9fa10ec6d30652244bb5e2a29694 Rework rendering for improved performance Approx 10-20% gain avg across several "benchmarks": x11perf, gtkperf, glxgears Moves from a single pre-alloc'd urb protected by a long-held mutex To a list of (4) pre-alloc'd urbs which can be dispatched asynchonously Improved rendering algorithm to hardware with lower CPU consumption, fewer system memory accesses, and slightly higher compression. Better scalability to multiple processors, especially with multiple framebuffers active. Signed-off-by: Bernie Thompson <bernie@plugable.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Rework rendering for improved performance

Approx 10-20% gain avg across several "benchmarks": x11perf, gtkperf, glxgears
Moves from a single pre-alloc'd urb protected by a long-held mutex
To a list of (4) pre-alloc'd urbs which can be dispatched asynchonously

Improved rendering algorithm to hardware with lower CPU consumption,
fewer system memory accesses, and slightly higher compression.

Better scalability to multiple processors, especially with
multiple framebuffers active.

Signed-off-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: udlfb: Rework startup and teardown to fix race conditions 2010-03-04T00:43:00+00:00 Bernie Thompson bernie@plugable.com 2010-02-15T14:46:13+00:00 2469d5dbcafe064859475a8aaf8da00ab33d440c Rework probe to use refcounts and std functions Because the different parts of the driver (usb, fbdev) tear down in different orders, the driver previously could crash accessing data that had already been freed. Refcounting system used to handle. Reworked probe to make use of refcounts, set mode using std fbops, and set up sysfs and pre-allocated urbs. Signed-off-by: Bernie Thompson <bernie@plugable.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Rework probe to use refcounts and std functions

Because the different parts of the driver (usb, fbdev) tear down
in different orders, the driver previously could crash accessing
data that had already been freed.  Refcounting system used to handle.

Reworked probe to make use of refcounts, set mode using std fbops,
and set up sysfs and pre-allocated urbs.

Signed-off-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: udlfb: Add functions to expose sysfs metrics and controls 2010-03-04T00:43:00+00:00 Bernie Thompson bernie@plugable.com 2010-02-15T14:46:08+00:00 7d9485e2c53caaaed9606a39de1c2746cc9ba262 Add sysfs controls for edid and performance metrics There are 8 new files exposed in /sys/class/graphics/fb* edid - returns 128 byte edid blog, suitable for parsing with parse-edid metrics_bytes_identical metrics_bytes_rendered metrics_bytes_sent metrics_cpu_kcycles_used metrics_misc and metrics_reset, which resets all perf metrics to zero The 6 perf metrics are of type atomic_t. So these metrics return precise results for short benchmarks, but any test approx a minute or longer runtime may roll over. Signed-off-by: Bernie Thompson <bernie@plugable.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Add sysfs controls for edid and performance metrics

There are 8 new files exposed in /sys/class/graphics/fb*

edid - returns 128 byte edid blog, suitable for parsing with parse-edid
metrics_bytes_identical
metrics_bytes_rendered
metrics_bytes_sent
metrics_cpu_kcycles_used
metrics_misc
and metrics_reset, which resets all perf metrics to zero

The 6 perf metrics are of type atomic_t.
So these metrics return precise results for short benchmarks, but
any test approx a minute or longer runtime may roll over.

Signed-off-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: udlfb: clean up function naming 2010-03-04T00:42:59+00:00 Bernie Thompson bernie@plugable.com 2010-02-15T14:46:04+00:00 4574203f45eb26b3fd76a171a77dd298dc1dc1ae Move to more consistent naming scheme All udlfb functions start with udlfb_ All functions for udlfb's fbdev interface start with udlfb_ops_ All functinos for udlfb's usb interface start with udlfb_usb_ Signed-off-by: Bernie Thompson <bernie@plugable.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Move to more consistent naming scheme

All udlfb functions start with udlfb_
All functions for udlfb's fbdev interface start with udlfb_ops_
All functinos for udlfb's usb interface start with udlfb_usb_

Signed-off-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: udlfb: pre-allocated urb list helpers 2010-03-04T00:42:59+00:00 Bernie Thompson bernie@plugable.com 2010-02-15T14:45:55+00:00 4a4854dd2049ddc066a162a0f843dc2a78481060 Add functions to pre-allocate and free usb bulk urbs for core render path. Udlfb currently allocates a single urb, guarded by a mutex, that is a key bottleneck. Because udlfb sends so much data, preallocation is most efficient. Functions will be used by new rendering functions in later patches. Signed-off-by: Bernie Thompson <bernie@plugable.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Add functions to pre-allocate and free usb bulk urbs for core render path.

Udlfb currently allocates a single urb, guarded by a mutex, that is a key
bottleneck. Because udlfb sends so much data, preallocation is most efficient.

Functions will be used by new rendering functions in later patches.

Signed-off-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: udlfb: reorganize function order 2010-03-04T00:42:59+00:00 Bernie Thompson bernie@plugable.com 2010-02-15T14:45:49+00:00 cc403dc67d10b895fec14b837fa2a6cb6ee6c8bd Reorganize the location of a few things to be closer to related code Signed-off-by: Bernie Thompson <bernie@plugable.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Reorganize the location of a few things to be closer to related code

Signed-off-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>