linux-toradex.git/drivers/video, branch v3.1.1

viafb: improve pitch handling

2011-11-11T17:43:26+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:43:25+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:43:25+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:43:24+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:43:24+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

backlight: Declare backlight_types[] const

2011-09-10T21:00:02+00:00

Since backlight_types[] isn't modified, let's declare it const.  That
was probably the intention of the author of commit bb7ca747f8d6
("backlight: add backlight type"), via which the "const char const *"
construct was introduced.  The duplicate const was detected by sparse.

Signed-off-by: Bart Van Assche 
Cc: Matthew Garrett 
Cc: Richard Purdie 
Cc: Florian Tobias Schandinat 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds

backlight: fix module alias prefix for adp8870_bl

2011-08-25T23:25:34+00:00

This is an i2c driver, not a platform driver, thus use "i2c" prefix for
the module alias.

Signed-off-by: Axel Lin 
Acked-by: Michael Hennerich 
Cc: Richard Purdie 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

backlight: add a callback 'notify_after' for backlight control

2011-08-25T23:25:34+00:00

We need a callback to do some things after pwm_enable, pwm_disable
and pwm_config.

Signed-off-by: Dilan Lee 
Reviewed-by: Robert Morell 
Reviewed-by: Arun Murthy 
Cc: Richard Purdie 
Cc: Paul Mundt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

drivers/video/backlight/ep93xx_bl.c: add missing include of linux/module.h

2011-08-25T23:25:34+00:00

ep93xx_bl.c uses interfaces from linux/module.h, so it should include
that file.  This patch fixes build errors:

    CC [M]  drivers/video/backlight/ep93xx_bl.o
  drivers/video/backlight/ep93xx_bl.c:138: error: 'THIS_MODULE' undeclared here (not in a function)
  drivers/video/backlight/ep93xx_bl.c:158: error: expected declaration specifiers or '...' before string constant
  drivers/video/backlight/ep93xx_bl.c:158: warning: data definition has no type or storage class
  ...

Signed-off-by: Axel Lin 
Acked-by: H Hartley Sweeten 
Cc: Ryan Mallon 
Cc: Richard Purdie 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

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

2011-08-06T19:02:40+00:00

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