linux-stable.git/drivers/video, branch v3.12.20

tgafb: fix data copying

2014-05-15T07:56:10+00:00

commit 6b0df6827bb6fcacb158dff29ad0a62d6418b534 upstream.

The functions for data copying copyarea_foreward_8bpp and
copyarea_backward_8bpp are buggy, they produce screen corruption.

This patch fixes the functions and moves the logic to one function
"copyarea_8bpp". For simplicity, the function only handles copying that
is aligned on 8 pixes. If we copy an unaligned area, generic function
cfb_copyarea is used.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

mach64: fix cursor when character width is not a multiple of 8 pixels

2014-05-15T07:55:58+00:00

commit 43751a1b8ee2e70ce392bf31ef3133da324e68b3 upstream.

This patch fixes the hardware cursor on mach64 when font width is not a
multiple of 8 pixels.

If you load such a font, the cursor is expanded to the next 8-byte
boundary and a part of the next character after the cursor is not
visible.
For example, when you load a font with 12-pixel width, the cursor width
is 16 pixels and when the cursor is displayed, 4 pixels of the next
character are not visible.

The reason is this: atyfb_cursor is called with proper parameters to
load an image that is 12-pixel wide. However, the number is aligned on
the next 8-pixel boundary on the line
"unsigned int width = (cursor->image.width + 7) >> 3;" and the whole
function acts as it is was loading a 16-pixel image.

This patch fixes it so that the value written to the framebuffer is
padded with 0xaaaa (the transparent pattern) when the image size it not
a multiple of 8 pixels. The transparent pattern causes that the cursor
will not interfere with the next character.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

mach64: use unaligned access

2014-05-15T07:55:57+00:00

commit c29dd8696dc5dbd50b3ac441b8a26751277ba520 upstream.

This patch fixes mach64 to use unaligned access to the font bitmap.

This fixes unaligned access warning on sparc64 when 14x8 font is loaded.

On x86(64), unaligned access is handled in hardware, so both functions
le32_to_cpup and get_unaligned_le32 perform the same operation.

On RISC machines, unaligned access is not handled in hardware, so we
better use get_unaligned_le32 to avoid the unaligned trap and warning.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

matroxfb: restore the registers M_ACCESS and M_PITCH

2014-05-15T07:55:57+00:00

commit a772d4736641ec1b421ad965e13457c17379fc86 upstream.

When X11 is running and the user switches back to console, the card
modifies the content of registers M_MACCESS and M_PITCH in periodic
intervals.

This patch fixes it by restoring the content of these registers before
issuing any accelerator command.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

framebuffer: fix cfb_copyarea

2014-05-15T07:55:56+00:00

commit 00a9d699bc85052d2d3ed56251cd928024ce06a3 upstream.

The function cfb_copyarea is buggy when the copy operation is not aligned on
long boundary (4 bytes on 32-bit machines, 8 bytes on 64-bit machines).

How to reproduce:
- use x86-64 machine
- use a framebuffer driver without acceleration (for example uvesafb)
- set the framebuffer to 8-bit depth
	(for example fbset -a 1024x768-60 -depth 8)
- load a font with character width that is not a multiple of 8 pixels
	note: the console-tools package cannot load a font that has
	width different from 8 pixels. You need to install the packages
	"kbd" and "console-terminus" and use the program "setfont" to
	set font width (for example: setfont Uni2-Terminus20x10)
- move some text left and right on the bash command line and you get a
	screen corruption

To expose more bugs, put this line to the end of uvesafb_init_info:
info->flags |= FBINFO_HWACCEL_COPYAREA | FBINFO_READS_FAST;
- Now framebuffer console will use cfb_copyarea for console scrolling.
You get a screen corruption when console is scrolled.

This patch is a rewrite of cfb_copyarea. It fixes the bugs, with this
patch, console scrolling in 8-bit depth with a font width that is not a
multiple of 8 pixels works fine.

The cfb_copyarea code was very buggy and it looks like it was written
and never tried with non-8-pixel font.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

video: atmel_lcdfb: ensure the hardware is initialized with the correct mode

2014-05-15T07:55:25+00:00

commit 7d3477d801808a5037a511cf5a5aae5718e7ecce upstream.

If no driver takeover the atmel_lcdfb, the lcd won't be in a working state
since atmel_lcdfb_set_par() will never be called. Enabling a driver which does,
like fbcon, will call the function and put atmel_lcdfb in a working state.

Fixes: b985172b328a (video: atmel_lcdfb: add device tree suport)

Signed-off-by: Antoine Ténart 
Reported-by: Alexandre Belloni 
Acked-by: Alexandre Belloni 
Acked-by: Nicolas Ferre 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

fbdev: Make the switch from generic to native driver less alarming

2014-04-18T09:04:16+00:00

commit 13ba0ad4490c3dd08b15c430a7a01c6fb45d5bce upstream.

Calling this "conflicting" just makes people think there's a problem
when there's not.

Signed-off-by: Adam Jackson 
Reviewed-by: David Herrmann 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

video/fb: Propagate error code from failing to unregister conflicting fb

2014-04-18T09:03:59+00:00

commit 46eeb2c144956e88197439b5ee5cf221a91b0a81 upstream.

If we fail to remove a conflicting fb driver, we need to abort the
loading of the second driver to avoid likely kernel panics.

Signed-off-by: Chris Wilson 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jiri Slaby

fb: reorder the lock sequence to fix potential dead lock

2014-04-18T09:03:37+00:00

commit 3a41c5dbe8bc396a7fb16ca8739e945bb003342e upstream.

Following commits:

50e244cc79 fb: rework locking to fix lock ordering on takeover
e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
054430e773 fbcon: fix locking harder

reworked locking to fix related lock ordering on takeover, and introduced console_lock
into fbmem, but it seems that the new lock sequence(fb_info->lock ---> console_lock)
is against with the one in console_callback(console_lock ---> fb_info->lock), and leads to
a potential dead lock as following:

[  601.079000] ======================================================
[  601.079000] [ INFO: possible circular locking dependency detected ]
[  601.079000] 3.11.0 #189 Not tainted
[  601.079000] -------------------------------------------------------
[  601.079000] kworker/0:3/619 is trying to acquire lock:
[  601.079000]  (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x26/0x60
[  601.079000]
but task is already holding lock:
[  601.079000]  (console_lock){+.+.+.}, at: [] console_callback+0x13/0x160
[  601.079000]
which lock already depends on the new lock.

[  601.079000]
the existing dependency chain (in reverse order) is:
[  601.079000]
-> #1 (console_lock){+.+.+.}:
[  601.079000]        [] lock_acquire+0xa1/0x140
[  601.079000]        [] console_lock+0x77/0x80
[  601.079000]        [] register_framebuffer+0x1d8/0x320
[  601.079000]        [] efifb_probe+0x408/0x48f
[  601.079000]        [] platform_drv_probe+0x43/0x80
[  601.079000]        [] driver_probe_device+0x8b/0x390
[  601.079000]        [] __driver_attach+0xab/0xb0
[  601.079000]        [] bus_for_each_dev+0x5d/0xa0
[  601.079000]        [] driver_attach+0x1e/0x20
[  601.079000]        [] bus_add_driver+0x117/0x290
[  601.079000]        [] driver_register+0x7a/0x170
[  601.079000]        [] __platform_driver_register+0x4a/0x50
[  601.079000]        [] platform_driver_probe+0x1d/0xb0
[  601.079000]        [] efifb_init+0x273/0x292
[  601.079000]        [] do_one_initcall+0x102/0x1c0
[  601.079000]        [] kernel_init_freeable+0x15d/0x1ef
[  601.079000]        [] kernel_init+0xe/0xf0
[  601.079000]        [] ret_from_fork+0x7c/0xb0
[  601.079000]
-> #0 (&fb_info->lock){+.+.+.}:
[  601.079000]        [] __lock_acquire+0x1e18/0x1f10
[  601.079000]        [] lock_acquire+0xa1/0x140
[  601.079000]        [] mutex_lock_nested+0x7a/0x3b0
[  601.079000]        [] lock_fb_info+0x26/0x60
[  601.079000]        [] fbcon_blank+0x29b/0x2e0
[  601.079000]        [] do_blank_screen+0x1d8/0x280
[  601.079000]        [] console_callback+0x64/0x160
[  601.079000]        [] process_one_work+0x1f5/0x540
[  601.079000]        [] worker_thread+0x11c/0x370
[  601.079000]        [] kthread+0xed/0x100
[  601.079000]        [] ret_from_fork+0x7c/0xb0
[  601.079000]
other info that might help us debug this:

[  601.079000]  Possible unsafe locking scenario:

[  601.079000]        CPU0                    CPU1
[  601.079000]        ----                    ----
[  601.079000]   lock(console_lock);
[  601.079000]                                lock(&fb_info->lock);
[  601.079000]                                lock(console_lock);
[  601.079000]   lock(&fb_info->lock);
[  601.079000]
 *** DEADLOCK ***

so we reorder the lock sequence the same as it in console_callback() to
avoid this issue. And following Tomi's suggestion, fix these similar
issues all in fb subsystem.

Signed-off-by: Gu Zheng 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

fbmem: really support wildcard video=options for all fbdev drivers

2014-04-03T08:32:12+00:00

commit f5d2b7c28b67d627646b6a0142bc201a7b1516b0 upstream.

Documentation/fb/modedb.txt states that video=option should be
considered a global option. But video_setup and fb_get_options are not
coded that way. Instead its required to boot with video=driver:option to
set a given option in drvier.  This is cumbersome because it requires to
know in advance which driver will be active for a given board/kernel.

The following patch implements the documented catchall for the fbdev
drivers. It is now possible to boot with video=XxY without the need to
know the active driver in advance. The specific case it tries to fix is
syslinux in the SUSE installer which offers a menu to set a display
resolution. Right now this just appends the vga= option the kernel. But
in addition to vga= it should be possible to pass a generic video=XxY
for all framebuffer/drm drivers. With this change forcing a certain
window size of VM displays is now much easier.

Today the video= option is stored in a global fb_mode_option. But
unfortunately only drm uses it.

Note: this change introduces a small memleak if video=option is actually
used because fb_mode_option is const. Most drivers use strsep to get to
individual options. This could be fixed in a followup patch which always
releases the option string in every caller of fb_get_options.

Signed-off-by: Olaf Hering 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby