summaryrefslogtreecommitdiffstats
path: root/drivers/video/p9100.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* p9100: use standard fields for framebuffer physical address and lengthKrzysztof Helt2009-06-161-12/+8
| | | | | | | | | | | 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>
* sparc: Annotate of_device_id arrays with const or __initdata.David S. Miller2008-08-311-1/+1
| | | | | | As suggested by Stephen Rothwell. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc video: remove open boot prom codeRobert Reif2008-05-091-3/+2
| | | | | | | | | 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>
* sparc video: make blank use proper constantRobert Reif2008-05-041-1/+1
| | | | | | | 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>
* sparc: video drivers: add facility levelRobert Reif2008-04-281-1/+1
| | | | | | | 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>
* [VIDEO]: Fix OOPS in all SBUS framebuffer drivers.David S. Miller2007-07-301-75/+63
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* [SPARC64]: Fix of_iounmap() region release.David S. Miller2006-12-311-10/+15
| | | | | | | | | | 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>
* [SPARC]: Convert all FB SBUS drivers to of_driver framework.David S. Miller2006-06-301-120/+131
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [PATCH] fbdev: Sanitize ->fb_mmap prototypeChristoph Hellwig2006-01-151-2/+2
| | | | | | | | | | | 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>
* [PATCH] fbdev: Sanitize ->fb_ioctl prototypeChristoph Hellwig2006-01-151-4/+3
| | | | | | | | | | | 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>
* [SBUSFB]: Kill 'list' member from foo_par structs, totally unused.David S. Miller2005-12-121-1/+0
| | | | | | Based upon a patch from Hareesh Nagarajan. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SBUSFB]: implement ->compat_ioctlChristoph Hellwig2005-11-121-0/+3
| | | | | | | | | | | | | 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>
* [PATCH] fbcon/fbdev: Move softcursor out of fbdev to fbconAntonino A. Daplas2005-11-071-1/+0
| | | | | | | | | | | | | | | | | | | | 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>
* [SPARC]: Fix p9100 framebuffer in 2.6Tom 'spot' Callaway2005-10-071-0/+4
| | | | | | | | | | | | | | The attached patch fixes the p9100 framebuffer so that text is viewable (not black on black, like it was before the patch). The linux logo displays for a very short period of time, then is replaced by a grey box. This leads me to believe that this framebuffer would have problems in X, but since there hasn't been a weitek driver for X in several millennia, this isn't something that I can confirm or deny. But this patch does get color console working on my SPARCbook 3TX. Signed-off-by: Tom 'spot' Callaway <tcallawa@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-171-0/+379
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!