summaryrefslogtreecommitdiff
path: root/drivers/video/omap/omapfb_main.c
AgeCommit message (Collapse)Author
2014-04-17video: move fbdev to drivers/video/fbdevTomi Valkeinen
The drivers/video directory is a mess. It contains generic video related files, directories for backlight, console, linux logo, lots of fbdev device drivers, fbdev framework files. Make some order into the chaos by creating drivers/video/fbdev directory, and move all fbdev related files there. No functionality is changed, although I guess it is possible that some subtle Makefile build order related issue could be created by this patch. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Rob Clark <robdclark@gmail.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-20video: omapfb: use dev_get_platdata()Jingoo Han
Use the wrapper function for retrieving the platform data instead of accessing dev->platform_data directly. This is a cosmetic change to make the code simpler and enhance the readability. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-03-22omapfb: fix broken build on OMAP1Aaro Koskinen
Fix the following build regression in 3.9-rc1 by including <mach/hardware.h>: drivers/video/omap/omapfb_main.c: In function 'set_fb_var': drivers/video/omap/omapfb_main.c:505:3: error: implicit declaration of function 'cpu_is_omap15xx' [-Werror=implicit-function-declaration] Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-11-30ARM: OMAP: Move plat-omap/dma-omap.h to include/linux/omap-dma.hTony Lindgren
Based on earlier discussions[1] we attempted to find a suitable location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion to dmaengine is complete. Unfortunately that was before I was able to try to test compile of the ARM multiplatform builds for omap2+, and the end result was not very good. So I'm creating yet another all over the place patch to cut the last dependency for building omap2+ for ARM multiplatform. After this, we have finally removed the driver dependencies to the arch/arm code, except for few drivers that are being worked on. The other option was to make the <plat-omap/dma-omap.h> path to work, but we'd have to add some new header directory to for multiplatform builds. Or we would have to manually include arch/arm/plat-omap/include again from arch/arm/Makefile for omap2+. Neither of these alternatives sound appealing as they will likely lead addition of various other headers exposed to the drivers, which we want to avoid for the multiplatform kernels. Since we already have a minimal include/linux/omap-dma.h, let's just use that instead and add a note to it to not use the custom omap DMA functions any longer where possible. Note that converting omap DMA to dmaengine depends on dmaengine supporting automatically incrementing the FIFO address at the device end, and converting all the remaining legacy drivers. So it's going to be few more merge windows. [1] https://patchwork.kernel.org/patch/1519591/# cc: Russell King <linux@arm.linux.org.uk> cc: Kevin Hilman <khilman@ti.com> cc: "Benoît Cousson" <b-cousson@ti.com> cc: Herbert Xu <herbert@gondor.apana.org.au> cc: "David S. Miller" <davem@davemloft.net> cc: Vinod Koul <vinod.koul@intel.com> cc: Dan Williams <djbw@fb.com> cc: Mauro Carvalho Chehab <mchehab@infradead.org> cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> cc: David Woodhouse <dwmw2@infradead.org> cc: Kyungmin Park <kyungmin.park@samsung.com> cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: Tomi Valkeinen <tomi.valkeinen@ti.com> cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> cc: Hans Verkuil <hans.verkuil@cisco.com> cc: Vaibhav Hiremath <hvaibhav@ti.com> cc: Lokesh Vutla <lokeshvutla@ti.com> cc: Rusty Russell <rusty@rustcorp.com.au> cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> cc: Afzal Mohammed <afzal@ti.com> cc: linux-crypto@vger.kernel.org cc: linux-media@vger.kernel.org cc: linux-mtd@lists.infradead.org cc: linux-usb@vger.kernel.org cc: linux-fbdev@vger.kernel.org Acked-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-15ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.hLokesh Vutla
Move plat/dma.h to plat-omap/dma-omap.h as part of single zImage work Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-09-07OMAPFB1: remove a non-used tableTomi Valkeinen
The old omapfb driver contains a table for DMA element types, which is not used. Remove it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-23OMAPFB: remove remaining OMAP arch checksTomi Valkeinen
Now that the old omapfb driver is only omap1 display driver, there's no need to check if the arch is omap1. This patch removes the few remaining checks for the arch. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
2012-02-23OMAPFB: remove mem info from platform_dataTomi Valkeinen
omapfb driver used platform_data to get fb memory areas and formats defined by the board file. This patch removes omapfb's (both old and new omapfb) use of the memory data in platform_data, because: - No board uses them currently - It's not board file's job to define things like amount of default framebuffer memory. These should come from the bootloader via command line parameters. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-23OMAPFB: Remove video SRAM support (old omapfb)Tomi Valkeinen
OMAP SRAM can be used as video memory on OMAP1 and 2. However, there usually is very little SRAM available, thus limiting its use, and no board supported by the kernel currently uses it. This patch removes the use of SRAM as video ram for the old omapfb driver to simplify memory handling. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
2012-02-22OMAPFB: Remove OMAP2/3 support from old omapfb driverTomi Valkeinen
Old omapfb driver (drivers/video/omap/) is no longer used for OMAP2+ devices, and thus we can remove OMAP2+ support from it and make it an OMAP1 omapfb driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-02-22OMAPFB: remove old blizzard driverTomi Valkeinen
N8x0's blizzard driver has been ported to new omapdss driver, so we can now remove the old blizzard driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-01-13module_param: make bool parameters really bool (drivers & misc)Rusty Russell
module_param(bool) used to counter-intuitively take an int. In fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy trick. It's time to remove the int/unsigned int option. For this version it'll simply give a warning, but it'll break next kernel version. Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2011-10-31video: Add module.h to drivers/video files who really use it.Paul Gortmaker
They were getting this implicitly by an include of module.h from device.h -- but we are going to clean that up and break that include chain, so include module.h explicitly now. [ with contributions from Axel Lin <axel.lin@gmail.com> ] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-05-12OMAPFB: fix wrong clock aliases and device nameTomi Valkeinen
The clock aliases and the dss platform device name have changed, and omapfb fails to initialize. Update the names to correct ones. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo
implicit slab.h inclusion from percpu.h 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>
2010-02-12omapfb: Fix 12-bit display (RGB444 color mode) handlingJanusz Krzysztofik
Support for RGB444 (12-bit) pixel format has been introduced into omapfb/lcdc by Mark Underwood on 2006-05-26 (commit f74edb6668aad9fc8e81585861b18f996c78a574) in preparation for Amstrad Delta (E3) videophone LCD display support. Before the Amstrad Delta LCD patch by Jonathan McDowell was applied (on 2006-08-04, commit 8d22fb2ea004cdb6379b54c1a8fd1546cfe40ed7), omapfb and lcdc code was changed substantially (commit e563dc81aa01bd8bbb01bc53975a15c398715f62 dated 2006-06-26) in a way that broke Mark's 12-bit display support. Than, a patch by Jonathan, that supposed to correct the problem, was introduced immediatelly (on 2006-08-04, commit e10a75b49e7a57ae17c28b705153c70eba15a8ef). As a result, the Amstrad Delta display was working correctly at boot time, with fbset reporting: geometry 480 320 480 320 16 ... rgba 4/8,4/4,4/0,0/0 However, after first framebuffer reinitialization, colors were no longer being displayed correctly and fbset was reporting: rgba 5/11,6/5,5/0,0/0 The patch tries to correct the issue by setting plane->color_mode depending on panel->bpp, not var->bits_per_pixel. Created and tested on Amstrad Delta against linux-2.6.33-rc3. Signed-off-by: Janusz Krzysztofik <jkrzysz@tis.icnet.pl> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-01-11OMAP: OMAPFB: add dummy release function for omapdssTomi Valkeinen
This should fix: WARNING: at drivers/base/core.c:131 device_release+0x68/0x7c() Device 'omapdss' does not have a release() function, it is broken and must be fixed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-01-11OMAP: OMAPFB: fix clk_get for RFBITomi Valkeinen
omapfb platform device was still used to get clocks inside rfbi.c Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com> Tested-by: Sergey Lapin <slapin@ossfans.org>
2009-12-09OMAP: OMAPFB: split omapfb.hTomi Valkeinen
Split arch/arm/plat-omap/include/mach/omapfb.h into two files: include/linux/omapfb.h - ioctls etc for userspace and some kernel stuff for board files drivers/video/omap/omapfb.h - for omapfb internal use This cleans up omapfb.h and also makes it easier for the upcoming new DSS driver to co-exist with the old driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com> Acked-by: Tony Lindgren <tony@atomide.com>
2009-10-20omap: headers: Move remaining headers from include/mach to include/platTony Lindgren
Move the remaining headers under plat-omap/include/mach to plat-omap/include/plat. Also search and replace the files using these headers to include using the right path. This was done with: #!/bin/bash mach_dir_old="arch/arm/plat-omap/include/mach" plat_dir_new="arch/arm/plat-omap/include/plat" headers=$(cd $mach_dir_old && ls *.h) omap_dirs="arch/arm/*omap*/ \ drivers/video/omap \ sound/soc/omap" other_files="drivers/leds/leds-ams-delta.c \ drivers/mfd/menelaus.c \ drivers/mfd/twl4030-core.c \ drivers/mtd/nand/ams-delta.c" for header in $headers; do old="#include <mach\/$header" new="#include <plat\/$header" for dir in $omap_dirs; do find $dir -type f -name \*.[chS] | \ xargs sed -i "s/$old/$new/" done find drivers/ -type f -name \*omap*.[chS] | \ xargs sed -i "s/$old/$new/" for file in $other_files; do sed -i "s/$old/$new/" $file done done for header in $(ls $mach_dir_old/*.h); do git mv $header $plat_dir_new/ done Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-10-06omapfb: Condition mutex acquisitionSergio Aguirre
This fixes a bug introduced by this commit ID: commit 537a1bf059fa312355696fa6db80726e655e7f17 Author: Krzysztof Helt <krzysztof.h1@wp.pl> Date: Tue Jun 30 11:41:29 2009 -0700 fbdev: add mutex for fb_mmap locking In which a mutex was added when changing smem_start and smem_len fields, so the mutex inside the fb_mmap() call is actually used. The problem was that set_fb_fix, which modifies the above 2 fields, was called before and after registering the framebuffer, which when used before registration, lead to a failed attempt to use an uninitialized mutex. Solution: Don't use mutex before framebuffer registration. Signed-off-by: Sergio Aguirre <saaguirre@ti.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@nokia.com> Acked-by: Imre Deak <imre.deak@nokia.com> Tested-by: Cory Maccarrone <darkstar6262@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2009-09-23omapfb: fix coding style / remove dead linearun c
- use __iomem type attribute where appropriate - expand (a ? : b) to (a ? a : b) As suggested by Russel King <linux@arm.linux.org.uk> - remove a dead line from omapfb_main.c Signed-off-by: Arun C <arunedarath@mistralsolutions.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Imre Deak <imre.deak@nokia.com> Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-23omapfb: suspend/resume only if FB device is already initializedJouni Hogander
Check wether fbdev is NULL in suspend / resume functions. Fbdev is NULL, if there is no lcd or it is not enabled in configuration. Signed-off-by: Jouni Hogander <jouni.hogander@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Imre Deak <imre.deak@nokia.com> Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-09-23omapfb: add support for rotation on the Blizzard LCD ctrlRodrigo Vivi
The LCD controller (EPSON S1D13744) supports rotation (0, 90, 180 and 270 degrees) on hardware just setting the bits 0 and 1 of 0x28 register (LCD Panel Configuration Register). Now it is possible to use this caps only setting the angle degree on var rotate of fb_var_screeninfo using the FBIOPUT_VSCREENINFO ioctl. Fixed-by: Siarhei Siamashka <siarhei.siamashka@nokia.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@openbossa.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Imre Deak <imre.deak@nokia.com> Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-07-12omap: video: remove direct access of driver_dataGreg Kroah-Hartman
dev_set/get_drvdata() should be used instead, as driver_data is going away. Cc: Imre Deak <imre.deak@nokia.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Acked-by: Trilok Soni <soni.trilok@gmail.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Felipe Contreras <felipe.contreras@nokia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-30fbdev: add mutex for fb_mmap lockingKrzysztof Helt
Add a mutex to avoid a circular locking problem between the mm layer semaphore and fbdev ioctl mutex through the fb_mmap() call. Also, add mutex to all places where smem_start and smem_len fields change so the mutex inside the fb_mmap() is actually used. Changing of these fields before calling the framebuffer_register() are not mutexed. This is 2.6.31 material. It removes one lockdep (fb_mmap() and register_framebuffer()) but there is still another one (fb_release() and register_framebuffer()). It also cleans up handling of the smem_start and smem_len fields used by mutexed section of the fb_mmap(). Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-04-01omapfb: fix argument of blank operationFelipe Contreras
The blank operation should receive FB_BLANK_POWERDOWN, not VESA_POWERDOWN. Signed-off-by: Felipe Contreras <felipe.contreras@nokia.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Andrea Righi <righi.andrea@gmail.com> Acked-by: Trilok Soni <soni.trilok@gmail.com> Cc: Imre Deak <imre.deak@solidboot.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-12-01[ARM] omap: fix a pile of issuesRussell King
This patch fixes a number of sillies, from missing 'const' to using 'return' in void functions, to functions with no arguments not even 'void' and a cast which isn't required. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-09-05[ARM] omap: fix a load of "warning: symbol 'xxx' was not declared. Should it ↵Russell King
be static?" Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-09-05[ARM] omap: fix lots of 'Using plain integer as NULL pointer'Russell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-08-07[ARM] Move include/asm-arm/arch-* to arch/arm/*/include/machRussell King
This just leaves include/asm-arm/plat-* to deal with. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-08-07[ARM] Eliminate useless includes of asm/mach-types.hRussell King
There are 43 includes of asm/mach-types.h by files that don't reference anything from that file. Remove these unnecessary includes. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-07-24PAGE_ALIGN(): correctly handle 64-bit values on 32-bit architecturesAndrea Righi
On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit boundary. For example: u64 val = PAGE_ALIGN(size); always returns a value < 4GB even if size is greater than 4GB. The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for example): #define PAGE_SHIFT 12 #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT) #define PAGE_MASK (~(PAGE_SIZE-1)) ... #define PAGE_ALIGN(addr) (((addr)+PAGE_SIZE-1)&PAGE_MASK) The "~" is performed on a 32-bit value, so everything in "and" with PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary. Using the ALIGN() macro seems to be the right way, because it uses typeof(addr) for the mask. Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in include/linux/mm.h. See also lkml discussion: http://lkml.org/lkml/2008/6/11/237 [akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c] [akpm@linux-foundation.org: fix v850] [akpm@linux-foundation.org: fix powerpc] [akpm@linux-foundation.org: fix arm] [akpm@linux-foundation.org: fix mips] [akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c] [akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c] [akpm@linux-foundation.org: fix powerpc] Signed-off-by: Andrea Righi <righi.andrea@gmail.com> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-17OMAP: add TI OMAP framebuffer driverImre Deak
- Add Texas Instruments OMAP framebuffer driver. This driver is being used for various OMAP1/2 series based boards and products e.g Nokia N800 Internet Tablet, H4, H3, Siemens SX1 etc. - LCD panel registration and controller code is separated in different file and interfaces. Signed-off-by: Trilok Soni <soni.trilok@gmail.com> Cc: Tony Lindgren <tony@atomide.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>