1. 05 Oct, 2011 4 commits
    • Timur Tabi's avatar
      drivers/video: fsl-diu-fb: add several new video modes · 760af8f8
      Timur Tabi authored
      Add the following new video modes to the Freescale DIU framebuffer driver:
      
      640x480x60
      640x480x72
      640x480x75
      640x480x90
      640x480x100
      800x480x60
      800x600x60
      854x480x60
      1280x480x60
      1280x720x60
      1920x1080x60
      
      Also add margin data to the 320x240 video mode.  This mode was originally
      intended only for the AOIs (overlays) used on planes two and three, but with
      real margin data, it can now be used as an actual video mode.
      Video mode data is from earlier work done by Jerry Huang
      <Chang-Ming.Huang@freescale.com>.
      Signed-off-by: default avatarTimur Tabi <timur@freescale.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      760af8f8
    • Timur Tabi's avatar
      drivers/video: fsl-diu-fb: remove broken screen blanking support · 1738f6f8
      Timur Tabi authored
      The function which is supposed to provide screen blanking support doesn't
      actually do anything, so the framebuffer layer thinks the screen has
      been blanked when it really isn't.  Remove the code completely for now.
      
      A side-effect of this change is that the framebuffer console blanking now
      works correctly.  Presumably this is because the console now receives -EINVAL
      instead of '0' when it asks the driver to blank the screen, so the console
      does it manually now.
      
      A signficant refactoring of the driver is planned, and proper hardware
      blanking support will added afterwards.
      Signed-off-by: default avatarTimur Tabi <timur@freescale.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      1738f6f8
    • Timur Tabi's avatar
      drivers/video: fsl-diu-fb: move some definitions out of the header file · b715f9f0
      Timur Tabi authored
      Move several macros and structures from the Freescale DIU driver's header
      file into the source file, because they're only used by that file.  Also
      delete a few unused macros.
      
      The diu and diu_ad structures cannot be moved because they're being used
      by the MPC5121 platform file.  A future patch eliminate the need for
      the platform file to access these structs, so they'll be moved also.
      Signed-off-by: default avatarTimur Tabi <timur@freescale.com>
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      b715f9f0
    • 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 1 commit