1. 05 Oct, 2011 1 commit
    • Timur Tabi's avatar
      drivers/video: fsl-diu-fb: fix some ioctls · 36b0b1d4
      Timur Tabi authored
      Use the _IOx macros to define the ioctl commands, instead of hard-coded
      numbers.  Unfortunately, the original definitions of MFB_SET_PIXFMT and
      MFB_GET_PIXFMT used the wrong value for the size, so these macros have
      new values now.  To avoid breaking binary compatibility with older
      applications, we retain support for the original values, but the driver
      displays a warning message if they're used.
      
      Also remove the FBIOGET_GWINFO and FBIOPUT_GWINFO ioctls.  FBIOPUT_GWINFO
      was never implemented, and FBIOGET_GWINFO was never used by any
      application.
      Signed-off-by: default avatarTimur Tabi <timur@freescale.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      36b0b1d4
  2. 04 Oct, 2011 2 commits
  3. 03 Oct, 2011 4 commits
  4. 18 Sep, 2011 13 commits
  5. 14 Sep, 2011 3 commits
  6. 05 Sep, 2011 9 commits
  7. 02 Sep, 2011 4 commits
    • Bruno Prémont's avatar
      fb: sh-mobile: Fix deadlock risk between lock_fb_info() and console_lock() · 4a47a0e0
      Bruno Prémont authored
      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: default avatarBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: stable@kernel.org
      4a47a0e0
    • Herton Ronaldo Krzesinski's avatar
      fb: avoid possible deadlock caused by fb_set_suspend · 9e769ff3
      Herton Ronaldo Krzesinski authored
      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:
       [<ffffffff8141287a>] __mutex_lock_slowpath+0x11a/0x1e0
       [<ffffffff814142f2>] ? _raw_spin_lock_irq+0x22/0x40
       [<ffffffff814123d3>] mutex_lock+0x23/0x50
       [<ffffffff8125dfc5>] lock_fb_info+0x25/0x60
       [<ffffffff8125e3f0>] fb_set_suspend+0x20/0x80
       [<ffffffff81263e2f>] store_fbstate+0x4f/0x70
       [<ffffffff812e7f70>] dev_attr_store+0x20/0x30
       [<ffffffff811c46b4>] sysfs_write_file+0xd4/0x160
       [<ffffffff81155a26>] vfs_write+0xc6/0x190
       [<ffffffff81155d51>] sys_write+0x51/0x90
       [<ffffffff8100c012>] 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:
       [<ffffffff81411fe5>] schedule_timeout+0x215/0x310
       [<ffffffff81058051>] ? get_parent_ip+0x11/0x50
       [<ffffffff814130dd>] __down+0x6d/0xb0
       [<ffffffff81089f71>] down+0x41/0x50
       [<ffffffff810629ac>] acquire_console_sem+0x2c/0x50
       [<ffffffff812ca53d>] unbind_con_driver+0xad/0x2d0
       [<ffffffff8126f5f7>] fbcon_event_notify+0x457/0x890
       [<ffffffff814144ff>] ? _raw_spin_unlock_irqrestore+0x1f/0x50
       [<ffffffff81058051>] ? get_parent_ip+0x11/0x50
       [<ffffffff8141836d>] notifier_call_chain+0x4d/0x70
       [<ffffffff8108a3b8>] __blocking_notifier_call_chain+0x58/0x80
       [<ffffffff8108a3f6>] blocking_notifier_call_chain+0x16/0x20
       [<ffffffff8125dabb>] fb_notifier_call_chain+0x1b/0x20
       [<ffffffff8125e6ac>] unregister_framebuffer+0x7c/0x130
       [<ffffffff8125e8b3>] remove_conflicting_framebuffers+0x153/0x180
       [<ffffffff8125eef3>] register_framebuffer+0x93/0x2c0
       [<ffffffffa0331112>] drm_fb_helper_single_fb_probe+0x252/0x2f0 [drm_kms_helper]
       [<ffffffffa03314a3>] drm_fb_helper_initial_config+0x2f3/0x6d0 [drm_kms_helper]
       [<ffffffffa03318dd>] ? drm_fb_helper_single_add_all_connectors+0x5d/0x1c0 [drm_kms_helper]
       [<ffffffffa037b588>] intel_fbdev_init+0xa8/0x160 [i915]
       [<ffffffffa0343d74>] i915_driver_load+0x854/0x12b0 [i915]
       [<ffffffffa02f0e7e>] drm_get_pci_dev+0x19e/0x360 [drm]
       [<ffffffff8141821d>] ? sub_preempt_count+0x9d/0xd0
       [<ffffffffa0386f91>] i915_pci_probe+0x15/0x17 [i915]
       [<ffffffff8124481f>] local_pci_probe+0x5f/0xd0
       [<ffffffff81244f89>] pci_device_probe+0x119/0x120
       [<ffffffff812eccaa>] ? driver_sysfs_add+0x7a/0xb0
       [<ffffffff812ed003>] driver_probe_device+0xa3/0x290
       [<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0
       [<ffffffff812ed29b>] __driver_attach+0xab/0xb0
       [<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0
       [<ffffffff812ebd3e>] bus_for_each_dev+0x5e/0x90
       [<ffffffff812ecc2e>] driver_attach+0x1e/0x20
       [<ffffffff812ec6f2>] bus_add_driver+0xe2/0x320
       [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915]
       [<ffffffff812ed536>] driver_register+0x76/0x140
       [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915]
       [<ffffffff81245216>] __pci_register_driver+0x56/0xd0
       [<ffffffffa02f1264>] drm_pci_init+0xe4/0xf0 [drm]
       [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915]
       [<ffffffffa02e84a8>] drm_init+0x58/0x70 [drm]
       [<ffffffffa03aa094>] i915_init+0x94/0x96 [i915]
       [<ffffffff81002194>] do_one_initcall+0x44/0x190
       [<ffffffff810a066b>] sys_init_module+0xcb/0x210
       [<ffffffff8100c012>] 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=26232Signed-off-by: default avatarHerton Ronaldo Krzesinski <herton@mandriva.com.br>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: stable@kernel.org
      9e769ff3
    • Manuel Lauss's avatar
      fbdev: au1200fb: silence debug output · f49446eb
      Manuel Lauss authored
      it's annoying and takes up way too much space in dmesg.
      Signed-off-by: default avatarManuel Lauss <manuel.lauss@googlemail.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      f49446eb
    • Anatolij Gustschin's avatar
      video: mb862xx-i2c: fix for reliable decoder register access · 363d58f5
      Anatolij Gustschin authored
      Increase delay when polling for tx status. This fixes
      the unreliable video decoder i2c register access.
      Signed-off-by: default avatarAnatolij Gustschin <agust@denx.de>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      363d58f5
  8. 01 Sep, 2011 3 commits
    • Tomi Valkeinen's avatar
      fbdev: fix parsing of standard timings · 43dcd13b
      Tomi Valkeinen authored
      The standard timings parses uses 1:1 dimensions when the ratio in the
      EDID data is 0. However, for EDID 1.3 and later the dimensions are 16:10
      when the ratio is 0.
      
      Pass the version and revision numbers to get_std_timing() which can then
      make the right decision about dimensions.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      43dcd13b
    • Axel Lin's avatar
      video: nuc900fb: remove include of mach/clkdev.h · f88a91cc
      Axel Lin authored
      Since commit aa3831cf
      "ARM: Consolidate the clkdev header files",
      the header file arch/arm/mach-nuc93x/include/mach/clkdev.h is removed.
      
      This patch fixes below build error:
      
      drivers/video/nuc900fb.c:42:25: error: mach/clkdev.h: No such file or directory
      make[2]: *** [drivers/video/nuc900fb.o] Error 1
      make[1]: *** [drivers/video] Error 2
      make: *** [drivers] Error 2
      Signed-off-by: default avatarAxel Lin <axel.lin@gmail.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      f88a91cc
    • Axel Lin's avatar
      video: mxsfb: add missing include of linux/module.h · 36893674
      Axel Lin authored
      Include linux/module.h to fix below build error:
      
                       from drivers/video/mxsfb.c:42:
      arch/arm/mach-mxs/include/mach/memory.h:22:1: warning: this is the location of the previous definition
      drivers/video/mxsfb.c:574: error: 'THIS_MODULE' undeclared here (not in a function)
      drivers/video/mxsfb.c:893: warning: data definition has no type or storage class
      drivers/video/mxsfb.c:893: warning: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE'
      drivers/video/mxsfb.c:893: warning: parameter names (without types) in function declaration
      drivers/video/mxsfb.c:917: error: expected declaration specifiers or '...' before string constant
      drivers/video/mxsfb.c:917: warning: data definition has no type or storage class
      drivers/video/mxsfb.c:917: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION'
      drivers/video/mxsfb.c:917: warning: function declaration isn't a prototype
      drivers/video/mxsfb.c:918: error: expected declaration specifiers or '...' before string constant
      drivers/video/mxsfb.c:918: warning: data definition has no type or storage class
      drivers/video/mxsfb.c:918: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
      drivers/video/mxsfb.c:918: warning: function declaration isn't a prototype
      drivers/video/mxsfb.c:919: error: expected declaration specifiers or '...' before string constant
      drivers/video/mxsfb.c:919: warning: data definition has no type or storage class
      drivers/video/mxsfb.c:919: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
      drivers/video/mxsfb.c:919: warning: function declaration isn't a prototype
      make[2]: *** [drivers/video/mxsfb.o] Error 1
      make[1]: *** [drivers/video] Error 2
      make: *** [drivers] Error 2
      Signed-off-by: default avatarAxel Lin <axel.lin@gmail.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      36893674
  9. 30 Aug, 2011 1 commit