summaryrefslogtreecommitdiffstats
path: root/drivers/video/sm501fb.c
AgeCommit message (Collapse)AuthorFilesLines
2009-12-16sm501: implement acceleration featuresVincent Sanders1-13/+224
This patch provides the acceleration entry points for the SM501 framebuffer driver. This patch provides the sync, copyarea and fillrect entry points, using the SM501's 2D acceleration engine to perform the operations in-chip rather than across the bus. Signed-off-by: Ben Dooks <ben@simtec.co.uk> Signed-off-by: Simtec Linux Team <linux@simtec.co.uk> Signed-off-by: Vincent Sanders <vince@simtec.co.uk> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16sm501: fix use of old <asm/io.h> instead of <linux/io.h>Ben Dooks1-1/+1
Fix the old style use of <asm/io.h> by replacing it with <linux/io.h>. Signed-off-by: Ben Dooks <ben@simtec.co.uk> Signed-off-by: Simtec Linux Team <linux@simtec.co.uk> Cc: Vincent Sanders <vince@simtec.co.uk> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-16sm501: fix missing uses of resource_size()Ben Dooks1-5/+5
There are several places in the SM501 fb driver that could do with using resource_size() to calculate the size of a resource. Also fix a bug where request_mem_region() is being passed one too few bytes when requesting the register memory region, which was causing the following in /proc/iomem: 13e80000-13e8ffff : sm501-fb.0 13e80000-13e8fffe : sm501-fb fixed, this reads: 13e80000-13e8ffff : sm501-fb.0 13e80000-13e8ffff : sm501-fb Signed-off-by: Ben Dooks <ben@simtec.co.uk> Signed-off-by: Simtec Linux Team <linux@simtec.co.uk> Cc: Vincent Sanders <vince@simtec.co.uk> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-07-09sm501fb: fix regression with uninitalized fb_info->mm_lock mutexKrzysztof Helt1-3/+0
Remove call to the fb_set_par() before the register_framebuffer(). This fixes a problem with uninitialized the fb_info->mm_lock mutex introduced by the commit 537a1bf059f " fbdev: add mutex for fb_mmap locking" Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-07-08Revert "fb: Initialize fb_info mutexes in framebuffer_alloc()"Linus Torvalds1-0/+2
This reverts commit 4148df9b0f38bdd362dd91d52076926c11cbe5a9. Let's hope that the mm_lock initialization is now correct with all drivers, following Krzysztof's patches. Requested-by: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-07-06fb: Initialize fb_info mutexes in framebuffer_alloc()Paul Mundt1-2/+0
This way they'll be properly initialized early enough for users that may touch them before the framebuffer has been registered. Drivers that allocate their fb_info structure some other way (like matrocfb's broken static allocation) need to be fixed up appropriately. Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-07-04video: sm501fb: Early initialization of mm_lock mutex.Paul Mundt1-0/+2
Commit 537a1bf059fa312355696fa6db80726e655e7f17 (fbdev: add mutex for fb_mmap locking) introduces a ->mm_lock mutex for protecting smem assignments. Unfortunately in the case of sm501fb these happen quite early in the initialization code, well before the mutex_init() that takes place in register_framebuffer(), leading to: Badness at kernel/mutex.c:207 Pid : 1, Comm: swapper CPU : 0 Not tainted (2.6.31-rc1-00284-g529ba0d-dirty #2273) PC is at __mutex_lock_slowpath+0x72/0x1bc PR is at __mutex_lock_slowpath+0x66/0x1bc ... matroxfb appears to have the same issue and has solved it with an early mutex_init(), so we do the same for sm501fb. Signed-off-by: Paul Mundt <lethal@linux-sh.org> Cc: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-06-30fbdev: add mutex for fb_mmap lockingKrzysztof Helt1-8/+13
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-01sm501fb: check fb_alloc_cmap return value and handle failure properlyAndres Salomon1-1/+4
Signed-off-by: Andres Salomon <dilinger@debian.org> Acked-by: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-01-06sm501: unsigned ptr cannot be negativeroel kluin1-3/+3
unsigned ptr cannot be negative Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-24sm501: fixup allocation code to be 64bit resource compliantBen Dooks1-11/+42
As pointed out by Andrew Morton, we have a problem when setting the 64bit resources option. Alter the allocation routines to remove the need to use the start and end fields, use the proper HEAD_PANEL/HEAD_CRT and update the comments. Note, we also fix the bug where we failed to check the size of the CRT memory allocation. [akpm@linux-foundation.org: cleanup] Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-24sm501: restructure init to allow only 1 fb on an SM501Ben Dooks1-115/+149
Add the ability to register only one of the two possible main framebuffer devices on the SM501 by passing platform data for only the framebuffer that you are interested in having. As a side note, we update the init sequence to commonise the code that is executed twice, and fix a pair of missing frees that we didn't do on framebuffer exit, such as freeing the fb's cmap. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-24sm501: add inversion controls for VBIASEN and FPENBen Dooks1-4/+22
Add flags to allow the driver to invert the sense of both VBIASEN and FPEN signals comming from the SM501. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-05-24SM501: reverse FPEN/VBIASEN flags behaviourBen Dooks1-4/+4
To keep backwards compatibility, reverse the meanings of these flags so that when they are not set, the driver uses the original behvaiour. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Cc: Arnaud Patard <arnaud.patard@rtp-net.org> 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>
2008-03-04sm501fb: fix timing limitsVille Syrjala1-2/+4
Vertical sync height register can only hold 6 bits. Fix the hsync start test to use > instead of >=. Also add a few clarifying comments. Signed-off-by: Ville Syrjala <syrjala@sci.fi> Acked-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-04sm501fb: set transp.offset to 0 in 8bpp and 16bpp modesVille Syrjala1-0/+2
Even though it may not be strictly necessary transp.offset should probably be 0 when alpha channel is not available. Signed-off-by: Ville Syrjala <syrjala@sci.fi> Acked-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-04sm501fb: RGB offsets are reversed in 16bpp modesVille Syrjala1-4/+4
The RGB offsets were reversed in 16bpp modes. Simply trying to reverse the offsets when endianness differs is clearly the wrong thing to do but that is an issue for another patch. Signed-off-by: Ville Syrjala <syrjala@sci.fi> Acked-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-03-04sm501fb: direct color visual does not workVille Syrjala1-1/+3
The sm501fb palette code clearly does not handle direct color so change the driver to use true color visual for 16bpp. Signed-off-by: Ville Syrjala <syrjala@sci.fi> Acked-by: Magnus Damm <damm@igel.co.jp> Acked-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-06FB/SM501: ensure console suspended before saving stateBen Dooks1-6/+9
Move the console suspend to before we save the state of the framebuffer to ensure that it does not try and change the fb state again once we have copied it out. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Vincent Sanders <vince@simtec.co.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-06sm501fb: clear framebuffer memory and paletteMagnus Damm1-0/+8
Avoid displaying garbage on unused framebuffers. For most users a single framebuffer is used together with fbcon. sm501fb supports two framebuffers where one often is assigned to fbcon and the other one is left unused during the boot. The problem here is that framebuffers not in use by fbcon happen to display garbage. This can easily be solved by making sure that framebuffer memory and palette ram are cleared. The problem can be observed by using looking at the panel output (fb1) after booting the kernel with fbcon on crt (fb0). This is the default configuration. It's also possible to watch the garbage on the crt framebuffer by passing "fbcon=map:1" on the kernel cmdline. This will assign fbcon to the panel (fb1) and leave the crt (fb0) unused. Signed-off-by: Magnus Damm <damm@igel.co.jp> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-06sm501fb: control panel pin usage with platform data flagsMagnus Damm1-16/+25
This patch makes it possible to control panel pins usage with flags passed from the platform data. Without this patch the sm501fb driver always controls the VBIASEN and FPEN pins. The polarity and use of these pins are very platform specific, so this patch introduces the flags SM501FB_FLAG_PANEL_USE_VBIASEN and SM501FB_FLAG_PANEL_USE_FPEN which enable the use of these pins. This patch is needed to support the a Sharp LQ104V1DG21 lcd panel on SuperH platforms such as R2D-1 and R2D-PLUS boards. Letting the sm501fb driver control the FPEN and VBIASEN pins like today just results in lcd panel flicker. Signed-off-by: Magnus Damm <damm@igel.co.jp> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-03drivers/video/: Spelling fixesJoe Perches1-1/+1
Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Adrian Bunk <bunk@kernel.org>
2007-10-16sm501fb: Ensure panel interface is not tristated when setupBen Dooks1-0/+5
When we setup the panel interface whilst configuring the framebuffer, we should ensure the panel interface is not in tristate, in case the bootloader or previous setup has not enabled it. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Antonino Daplas <adaplas@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-16sm501fb: Call fb suspend function during suspend and resumeBen Dooks1-0/+9
Call the fb_set_suspend() over suspend and resume. Signed-off-by: Antonino Daplas <adaplas@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-16sm501fb: update suspend and resume codeBen Dooks1-4/+31
The suspend and resume code is failing to restore the CRT control register, thus causing the CRT data-path to get changed if the SM501 experiences a reset over suspend. Also move some of the debug messages to dev_dbg() level and ensure that the suspend code does not try and restore anything it did not manage to save. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Antonino Daplas <adaplas@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-08sm501fb printk warning fixesAndrew Morton1-1/+1
drivers/video/sm501fb.c: In function 'sm501fb_cursor': drivers/video/sm501fb.c:992: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'long unsigned int' drivers/video/sm501fb.c:992: warning: format '%08x' expects type 'unsigned int', but argument 4 has type 'long unsigned int' 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>
2007-03-05[PATCH] fb: sm501fb off-by-1 sysfs storePaul Mundt1-3/+3
Currently sm501fb_crtsrc_store() won't allow the routing to be changed via echos from userspace in to the sysfs file. The reason for this is that the strnicmp() for both heads uses a sizeof() for the string length, which ends up being strlen() + 1 (\0 in the normal case, but the echo gives a newline, which is where the issue occurs), this then causes a mismatch and subsequently bails with the -EINVAL. In addition to this, the hardcoded lengths were then used for the store length that was returned, which ended up being erroneous and resulting in a write error. There's also no point in returning anything but the full length since it will -EINVAL out on a mismatch well before then anyways. sizeof("string") is great for making sure you have space in your buffer, but rather less so for string comparisons :-) Signed-off-by: Paul Mundt <lethal@linux-sh.org> Acked-by: Ben Dooks <ben-linux@fluff.org> 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>
2007-03-01[PATCH] drivers/video/sm501fb.c: make 4 functions staticAdrian Bunk1-5/+5
Signed-off-by: Adrian Bunk <bunk@stusta.de> Cc: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-20[PATCH] fb: SM501 framebuffer driverBen Dooks1-0/+1786
Driver for the Silicon Motion SM501 multifunction device framebuffer subsystem. This driver supports both the CRT and LCD panel heads, with some simple acceleration for the cursor plotting and support for screen panning. There is no current support for bitblt/drawing engines, which should be added at a later date. This has been tested on a number of configurations, including PCI and generic-bus, on PPC, ARM and SH4 [akpm@linux-foundation.org: fix warnings] Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Vincent Sanders <vince@arm.linux.org.u.> Acked-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-16 09:45:54 +0000