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

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

vesafb: fix memory leak

2011-07-04T07:02:48+00:00

When releasing framebuffer, free colourmap allocations.

Signed-off-by: Daniel J Blueman 
Signed-off-by: Paul Mundt

fbdev: amba: Link fb device to its parent

2011-06-24T08:11:50+00:00

Some pieces of userspace like debian-installer expect to find the fb0
driver name by readlink-ing /sys/class/graphics/fb0/device/driver but
this was broken with amba-clcd as it sets up fb_info manually and missed
the .device parent pointer.

Signed-off-by: Loïc Minier 
Cc: Russell King 
Signed-off-by: Paul Mundt

fsl-diu-fb: remove check for pixel clock ranges

2011-06-24T08:08:49+00:00

The Freescale DIU framebuffer driver defines two constants, MIN_PIX_CLK and
MAX_PIX_CLK, that are supposed to represent the lower and upper limits of
the pixel clock.  These values, however, are true only for one platform
clock rate (533MHz) and only for the MPC8610.  So the actual range for
the pixel clock is chip-specific, which means the current values are almost
always wrong.  The chance of an out-of-range pixel clock being used are also
remote.

Rather than try to detect an out-of-range clock in the DIU driver, we depend
on the board-specific pixel clock function (e.g. p1022ds_set_pixel_clock)
to clamp the pixel clock to a supported value.

Signed-off-by: Timur Tabi 
Signed-off-by: Paul Mundt

udlfb: Correct sub-optimal resolution selection.

2011-06-24T08:08:44+00:00

The situation in which the problem occurred was with a Plugable UGA-2K-A
connected to a Samsung EX2220X display. The driver indicates that
1920x1080 is a valid mode (the first mode available, in fact), but
proceeds to set the framebuffer size to 1600x1200.

The patch corrects what seems to be a logic error, regarding unsetting
the FB_MISC_1ST_DETAIL flag, if the first (top/best) mode is invalid.
The existing code unset the flag if ANY mode was invalid.

Signed-off-by: William Katsak 
Signed-off-by: Paul Mundt