aboutsummaryrefslogtreecommitdiff
path: root/drivers/video/leo.c
AgeCommit message (Collapse)Author
2009-06-16leo: use standard fields for framebuffer physical address and lengthKrzysztof Helt
Use standard fields fbinfo.fix.smem_start and fbinfo.fix.smem_len for physical address and length of framebuffer. This also fixes output of the 'fbset -i' command - address and length of the framebuffer are displayed correctly. Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-10leo: disable cursor when leaving graphics modeRobert Reif
On sparc32 debian etch, the cursor is not disabled when leaving X windows. This patch disables the cursor when leaving graphics mode just like the ffb driver. Signed-off-by: Robert Reif <reif@earthlink.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-08-31sparc: Annotate of_device_id arrays with const or __initdata.David S. Miller
As suggested by Stephen Rothwell. Signed-off-by: David S. Miller <davem@davemloft.net>
2008-06-10sparc: get leo framebuffer workingRobert Reif
This patch fixes several issues: Use the right openprom device name so the driver is actually loaded. Fix a crash due to unitialized info->pseudo_palette. Put the framebuffer in the proper mode for software rendering. checkpatch cleanups. Hardware acceleration was removed when the driver was rewritten for the new framebuffer API in 2003. Software rendering requires a different framebuffer access mode but that wasn't changed. The driver now works again but is slow. The proper fix is to reintroduce hardware acceleration. Signed-off-by: Robert Reif <reif@earthlink.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-05-08sparc video: remove open boot prom codeRobert Reif
Replace remaining open boot prom code with of. Boot tested on sparc32 and compile tested on sparc64. Signed-off-by: Robert Reif <reif@earthlink.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-05-03sparc video: make blank use proper constantRobert Reif
Make blank functions use proper constant for unblanking. Signed-off-by: Robert Reif <reif@earthlink.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-04-27sparc: video drivers: add facility levelRobert Reif
Add KERN_ facility level to sparc video drivers. Signed-off-by: Robert Reif <reif@earthlink.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-07-30[VIDEO]: Fix OOPS in all SBUS framebuffer drivers.David S. Miller
All of these drivers use a silly: struct all_info { struct fb_info info; struct foo_par par; }; struct all_info *all = kzalloc(sizeof(*all), GFP_KERNEL); all->info.par = &all->par; etc. etc. code sequence, basically replicating the provided framebuffer_alloc()/framebuffer_release(), and doing it badly. Not only is this massive code duplication, it also caused a bug in that we weren't setting the fb_info->device pointer which results in an OOPS when fb_is_primary_device() runs. Fix all of this by using framebuffer_{alloc,release}() and passing in "&of_device->dev" as the device pointer. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-12-31[SPARC64]: Fix of_iounmap() region release.David S. Miller
We need to pass in the resource otherwise we cannot release the region properly. We must know whether it is an I/O or MEM resource. Spotted by Eric Brower. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-29[SPARC]: Convert all FB SBUS drivers to of_driver framework.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-01-14[PATCH] fbdev: Sanitize ->fb_mmap prototypeChristoph Hellwig
No need for a file argument. If we'd really need it it's in vma->vm_file already. gbefb and sgivwfb used to set vma->vm_file to the file argument, but the kernel alrady did that. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-14[PATCH] fbdev: Sanitize ->fb_ioctl prototypeChristoph Hellwig
The ioctl and file arguments to ->fb_mmap are totally unused and there's not reason a driver should need them. Also update the ->fb_compat_ioctl prototype to be the same as ->fb_mmap. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-12-12[SBUSFB]: Kill 'list' member from foo_par structs, totally unused.David S. Miller
Based upon a patch from Hareesh Nagarajan. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-11-12[SBUSFB]: implement ->compat_ioctlChristoph Hellwig
This patch adds a new function, sbusfb_compat_ioctl() to drivers/video/sbuslib.c and uses it as compat_ioctl in all sbus fb drivers This remove the last per-arch compat ioctl bits in arch/sparc64/kernel/ioctl32.c so it would be nice if people could test if this actually copiles and works and if yes apply it :) Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-11-07[PATCH] fbcon/fbdev: Move softcursor out of fbdev to fbconAntonino A. Daplas
According to Jon Smirl, filling in the field fb_cursor with soft_cursor for drivers that do not support hardware cursors is redundant. The soft_cursor function is usable by all drivers because it is just a wrapper around fb_imageblit. And because soft_cursor is an fbcon-specific hook, the file is moved to the console directory. Thus, drivers that do not support hardware cursors can leave the fb_cursor field blank. For drivers that do, they can fill up this field with their own version. The end result is a smaller code size. And if the framebuffer console is not loaded, module/kernel size is also reduced because the soft_cursor module will also not be loaded. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!