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

atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resume

2012-02-13T19:06:09+00:00

commit 9f1065032ceb7e86c7c9f16bb86518857e88a172 upstream.

An error was existing in the saving of CONTRAST_CTR register
across suspend/resume.

Signed-off-by: Hubert Feurstein 
Signed-off-by: Nicolas Ferre 
Acked-by: Jean-Christophe PLAGNIOL-VILLARD 
Signed-off-by: Florian Tobias Schandinat 
Signed-off-by: Greg Kroah-Hartman

offb: Fix bug in calculating requested vram size

2012-01-12T19:35:00+00:00

commit c055fe0797b7bd8f6f21a13598a55a16d5c13ae7 upstream.

We used to try to request 8 times more vram than needed, which would
fail if the card has a too small BAR (observed with qemu & kvm).

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

offb: Fix setting of the pseudo-palette for >8bpp

2012-01-12T19:34:59+00:00

commit 1bb0b7d21584b3f878e2bc880db62351ddee5185 upstream.

When using a >8bpp framebuffer, offb advertises truecolor, not directcolor,
and doesn't touch the color map even if it has a corresponding access method
for the real hardware.

Thus it needs to set the pseudo-palette with all 3 components of the color,
like other truecolor framebuffers, not with copies of the color index like
a directcolor framebuffer would do.

This went unnoticed for a long time because it's pretty hard to get offb
to kick in with anything but 8bpp (old BootX under MacOS will do that and
qemu does it).

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

viafb: correct sync polarity for OLPC DCON

2011-12-09T16:52:23+00:00

commit a32839696a8eef813a1aff604fbad9a32dff6c95 upstream.

While the OLPC display appears to be able to handle either positive
or negative sync, the Display Controller only recognises positive sync.

This brings viafb (for XO-1.5) in line with lxfb (for XO-1) and
fixes a recent regression where the XO-1.5 DCON could no longer be
frozen. Thanks to Florian Tobias Schandinat for helping identify
the fix.

Test case: from a vt,
	echo 1 > /sys/devices/platform/dcon/freeze
should cause the current screen contents to freeze, rather than garbage being
displayed.

Signed-off-by: Daniel Drake 
Signed-off-by: Florian Tobias Schandinat 
Signed-off-by: Greg Kroah-Hartman

viafb: improve pitch handling

2011-11-11T17:36:13+00:00

commit 936a3f770b8de7042d793272f008ef1bb08522e9 upstream.

This patch adds checks for minimum and maximum pitch size to prevent
invalid settings which could otherwise crash the machine. Also the
alignment is done in a slightly more readable way.

Signed-off-by: Florian Tobias Schandinat 
Signed-off-by: Greg Kroah-Hartman

viafb: use display information in info not in var for panning

2011-11-11T17:36:12+00:00

commit d933990c57b498c092ceef591c7c5d69dbfe9f30 upstream.

As Laurent pointed out we must not use any information in the passed
var besides xoffset, yoffset and vmode as otherwise applications
might abuse it. Also use the aligned fix.line_length and not the
(possible) unaligned xres_virtual.

Signed-off-by: Florian Tobias Schandinat 
Reported-by: Laurent Pinchart 
Acked-by: Laurent Pinchart 
Signed-off-by: Greg Kroah-Hartman

fb: sh-mobile: Fix deadlock risk between lock_fb_info() and console_lock()

2011-11-11T17:36:11+00:00

commit 4a47a0e09c504e3ce0ccdb405411aefc5b09deb8 upstream.

Following on Herton's patch "fb: avoid possible deadlock caused by
fb_set_suspend" which moves lock_fb_info() out of fb_set_suspend()
to its callers, correct sh-mobile's locking around call to
fb_set_suspend() and the same sort of deaklocks with console_lock()
due to order of taking the lock.

console_lock() must be taken while fb_info is already locked and fb_info
must be locked while calling fb_set_suspend().

Signed-off-by: Bruno Prémont 
Signed-off-by: Guennadi Liakhovetski 
Signed-off-by: Florian Tobias Schandinat 
Signed-off-by: Greg Kroah-Hartman

fb: avoid possible deadlock caused by fb_set_suspend

2011-11-11T17:36:10+00:00

commit 9e769ff3f585db8f978f9113be83d36c7e3965dd upstream.

A lock ordering issue can cause deadlocks: in framebuffer/console code,
all needed struct fb_info locks are taken before acquire_console_sem(),
in places which need to take console semaphore.

But fb_set_suspend is always called with console semaphore held, and
inside it we call lock_fb_info which gets the fb_info lock, inverse
locking order of what the rest of the code does. This causes a real
deadlock issue, when we write to state fb sysfs attribute (which calls
fb_set_suspend) while a framebuffer is being unregistered by
remove_conflicting_framebuffers, as can be shown by following show
blocked state trace on a test program which loads i915 and runs another
forked processes writing to state attribute:

Test process with semaphore held and trying to get fb_info lock:
..
fb-test2      D 0000000000000000     0   237    228 0x00000000
 ffff8800774f3d68 0000000000000082 00000000000135c0 00000000000135c0
 ffff880000000000 ffff8800774f3fd8 ffff8800774f3fd8 ffff880076ee4530
 00000000000135c0 ffff8800774f3fd8 ffff8800774f2000 00000000000135c0
Call Trace:
 [] __mutex_lock_slowpath+0x11a/0x1e0
 [] ? _raw_spin_lock_irq+0x22/0x40
 [] mutex_lock+0x23/0x50
 [] lock_fb_info+0x25/0x60
 [] fb_set_suspend+0x20/0x80
 [] store_fbstate+0x4f/0x70
 [] dev_attr_store+0x20/0x30
 [] sysfs_write_file+0xd4/0x160
 [] vfs_write+0xc6/0x190
 [] sys_write+0x51/0x90
 [] system_call_fastpath+0x16/0x1b
..
modprobe process stalled because has the fb_info lock (got inside
unregister_framebuffer) but waiting for the semaphore held by the
test process which is waiting to get the fb_info lock:
..
modprobe      D 0000000000000000     0   230    218 0x00000000
 ffff880077a4d618 0000000000000082 0000000000000001 0000000000000001
 ffff880000000000 ffff880077a4dfd8 ffff880077a4dfd8 ffff8800775a2e20
 00000000000135c0 ffff880077a4dfd8 ffff880077a4c000 00000000000135c0
Call Trace:
 [] schedule_timeout+0x215/0x310
 [] ? get_parent_ip+0x11/0x50
 [] __down+0x6d/0xb0
 [] down+0x41/0x50
 [] acquire_console_sem+0x2c/0x50
 [] unbind_con_driver+0xad/0x2d0
 [] fbcon_event_notify+0x457/0x890
 [] ? _raw_spin_unlock_irqrestore+0x1f/0x50
 [] ? get_parent_ip+0x11/0x50
 [] notifier_call_chain+0x4d/0x70
 [] __blocking_notifier_call_chain+0x58/0x80
 [] blocking_notifier_call_chain+0x16/0x20
 [] fb_notifier_call_chain+0x1b/0x20
 [] unregister_framebuffer+0x7c/0x130
 [] remove_conflicting_framebuffers+0x153/0x180
 [] register_framebuffer+0x93/0x2c0
 [] drm_fb_helper_single_fb_probe+0x252/0x2f0 [drm_kms_helper]
 [] drm_fb_helper_initial_config+0x2f3/0x6d0 [drm_kms_helper]
 [] ? drm_fb_helper_single_add_all_connectors+0x5d/0x1c0 [drm_kms_helper]
 [] intel_fbdev_init+0xa8/0x160 [i915]
 [] i915_driver_load+0x854/0x12b0 [i915]
 [] drm_get_pci_dev+0x19e/0x360 [drm]
 [] ? sub_preempt_count+0x9d/0xd0
 [] i915_pci_probe+0x15/0x17 [i915]
 [] local_pci_probe+0x5f/0xd0
 [] pci_device_probe+0x119/0x120
 [] ? driver_sysfs_add+0x7a/0xb0
 [] driver_probe_device+0xa3/0x290
 [] ? __driver_attach+0x0/0xb0
 [] __driver_attach+0xab/0xb0
 [] ? __driver_attach+0x0/0xb0
 [] bus_for_each_dev+0x5e/0x90
 [] driver_attach+0x1e/0x20
 [] bus_add_driver+0xe2/0x320
 [] ? i915_init+0x0/0x96 [i915]
 [] driver_register+0x76/0x140
 [] ? i915_init+0x0/0x96 [i915]
 [] __pci_register_driver+0x56/0xd0
 [] drm_pci_init+0xe4/0xf0 [drm]
 [] ? i915_init+0x0/0x96 [i915]
 [] drm_init+0x58/0x70 [drm]
 [] i915_init+0x94/0x96 [i915]
 [] do_one_initcall+0x44/0x190
 [] sys_init_module+0xcb/0x210
 [] system_call_fastpath+0x16/0x1b
..

fb-test2 which reproduces above is available on kernel.org bug #26232.
To solve this issue, avoid calling lock_fb_info inside fb_set_suspend,
and move it out to where needed (callers of fb_set_suspend must call
lock_fb_info before if needed). So far, the only place which needs to
call lock_fb_info is store_fbstate, all other places which calls
fb_set_suspend are suspend/resume hooks that should not need the lock as
they should be run only when processes are already frozen in
suspend/resume.

References: https://bugzilla.kernel.org/show_bug.cgi?id=26232
Signed-off-by: Herton Ronaldo Krzesinski 
Signed-off-by: Florian Tobias Schandinat 
Signed-off-by: Greg Kroah-Hartman

carminefb: Fix module parameters permissions

2011-11-11T17:36:10+00:00

commit c84c14224bbca6ec60d5851fcc87be0e34df2f44 upstream.

The third parameter of module_param is supposed to be an octal value.
The missing leading "0" causes the following:

$ ls -l /sys/module/carminefb/parameters/
total 0
-rw-rwxr-- 1 root root 4096 Jul  8 08:55 fb_displays
-rw-rwxr-- 1 root root 4096 Jul  8 08:55 fb_mode
-rw-rwxr-- 1 root root 4096 Jul  8 08:55 fb_mode_str

After fixing the perm parameter, we get the expected:

$ ls -l /sys/module/carminefb/parameters/
total 0
-r--r--r-- 1 root root 4096 Jul  8 08:56 fb_displays
-r--r--r-- 1 root root 4096 Jul  8 08:56 fb_mode
-r--r--r-- 1 root root 4096 Jul  8 08:56 fb_mode_str

Signed-off-by: Jean Delvare 
Cc: Paul Mundt 
Cc: Sebastian Siewior 
Signed-off-by: Paul Mundt 
Signed-off-by: Greg Kroah-Hartman

savagedb: Fix typo causing regression in savage4 series video chip detection

2011-10-03T18:39:57+00:00

commit 4b00e4b3940eabb38adeec0823751820fe2d6fda upstream.

Two additional savage4 variants were added, but the S3_SAVAGE4_SERIES
macro was incompletely modified, resulting in a false positive detection
of a savage4 card regardless of which savage card is actually present.

For non-savage4 series cards, such as a Savage/IX-MV card, this results
in garbled video and/or a hard-hang at boot time.  Fix this by changing
an '||' to an '&&' in the S3_SAVAGE4_SERIES macro.

Signed-off-by: John P. Stanley 
Reviewed-by: Tormod Volden 
[ The macros have incomplete parenthesis too, but whatever ..  -Linus ]
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman