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

OMAPDSS: HDMI: PHY burnout fix

2012-03-12T17:32:59+00:00

commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd upstream.

A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.

This patch solves the problem by adding hot-plug-detection into the HDMI
IP driver. This is not a real HPD support in the sense that nobody else
than the IP driver gets to know about the HPD events, but is only meant
to fix the HW bug.

The strategy is simple: If the display device is turned off by the user,
the PHY power is set to OFF. When the display device is turned on by the
user, the PHY power is set either to LDOON or TXON, depending on whether
the HDMI cable is connected.

The reason to avoid PHY OFF when the display device is on, but the cable
is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
"ticking" and thus the DISPC does not receive pixel clock from the HDMI
IP. This would, for example, prevent any VSYNCs from happening, and
would thus affect the users of omapdss. By using LDOON when the cable is
disconnected we'll avoid the HW bug, but keep the HDMI working as usual
from the user's point of view.

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman

OMAP: DSS2: HDMI: use default dividers

2012-03-12T17:32:58+00:00

commit 8d88767a4377171752c22ac39bcb2b505eb751da upstream.

Use default regn and regm2 dividers in the hdmi driver if the board file
does not define them.

Cc: Mythri P K 
Acked-by: Tony Lindgren 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman

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