16 Jun, 2009
1 commit
-
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 is displayed correctly.Signed-off-by: Krzysztof Helt
Signed-off-by: David S. Miller
31 Aug, 2008
1 commit
-
As suggested by Stephen Rothwell.
Signed-off-by: David S. Miller
09 May, 2008
1 commit
-
Replace remaining open boot prom code with of.
Boot tested on sparc32 and compile tested on sparc64.
Signed-off-by: Robert Reif
Signed-off-by: David S. Miller
28 Apr, 2008
2 commits
-
Add KERN_ facility level to sparc video drivers.
Signed-off-by: Robert Reif
Signed-off-by: David S. Miller -
Make cg14_init and cg14_exit static.
Signed-off-by: Robert Reif
Signed-off-by: David S. Miller
13 Feb, 2008
1 commit
-
Apparently these drivers now need uaccess.h
Signed-off-by: Robert Reif
Signed-off-by: Andrew Morton
Signed-off-by: David S. Miller
30 Jul, 2007
1 commit
-
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
10 Mar, 2007
1 commit
-
Fix section mismatch warning by moving data into __devinitdata section.
Add __devinit to an initialization function.Signed-off-by: Robert Reif
Signed-off-by: David S. Miller
01 Jan, 2007
1 commit
-
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
30 Jun, 2006
1 commit
-
Signed-off-by: David S. Miller
15 Jan, 2006
2 commits
-
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
Signed-off-by: Antonino Daplas
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Dec, 2005
1 commit
-
Based upon a patch from Hareesh Nagarajan.
Signed-off-by: David S. Miller
13 Nov, 2005
1 commit
-
This patch adds a new function, sbusfb_compat_ioctl() to
drivers/video/sbuslib.c and uses it as compat_ioctl in all sbus fb
driversThis 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
Signed-off-by: David S. Miller
07 Nov, 2005
1 commit
-
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
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2005
1 commit
-
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!