1. 24 10月, 2014 5 次提交
  2. 03 10月, 2014 3 次提交
  3. 01 10月, 2014 2 次提交
  4. 30 9月, 2014 1 次提交
  5. 29 9月, 2014 2 次提交
    • D
      Revert "drm/i915/bdw: BDW Software Turbo" · 7526ed79
      Daniel Vetter 提交于
      This reverts commit c76bb61a.
      
      It's apparently too broken so that Rodrigo submitted a patch to add a
      config option for it. Given that the design is also ... suboptimal and
      that I've only merged this to get lead engineers and managers off my
      back for one second let's just revert this.
      
      /me puts on combat gear again
      
      It was worth a shot ...
      
      References: http://mid.mail-archive.com/1411686380-1953-1-git-send-email-rodrigo.vivi@intel.com
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Daisy Sun <daisy.sun@intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      7526ed79
    • R
      drm/i915: Minimize the huge amount of unecessary fbc sw cache clean. · 1d73c2a8
      Rodrigo Vivi 提交于
      The sw cache clean on BDW is a tempoorary workaround because we cannot
      set cache clean on blt ring with risk of hungs. So we are doing the cache clean on sw.
      However we are doing much more than needed. Not only when using blt ring.
      So, with this extra w/a we minimize the ammount of cache cleans and call it only
      on same cases that it was being called on gen7.
      
      The traditional FBC Cache clean happens over LRI on BLT ring when there is a
      frontbuffer touch happening. frontbuffer tracking set fbc_dirty variable
      to let BLT flush that it must clean FBC cache.
      
      fbc.need_sw_cache_clean works in the opposite information direction
      of ring->fbc_dirty telling software on frontbuffer tracking to perform
      the cache clean on sw side.
      
      v2: Clean it a little bit and fully check for Broadwell instead of gen8.
      
      v3: Rebase after frontbuffer organization.
      
      v4: Wiggle confused me. So fixing v3!
      
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1d73c2a8
  6. 24 9月, 2014 5 次提交
  7. 23 9月, 2014 1 次提交
    • P
      drm/i915: add SW tracking to FBC enabling · 9adccc60
      Paulo Zanoni 提交于
      Currently, calling intel_fbc_enabled() will trigger a register read.
      And we call it a lot of times, even when FBC is disabled, so saving a
      few cycles would be a good thing.
      
      Another reason for this patch is because we currently call
      intel_fbc_enabled() while the HW is runtime suspended, so the read
      makes no sense and triggers a WARN. This happens even if FBC is
      disabled by default. Of course one could argue that we just shouldn't
      be calling intel_fbc_enabled() while the driver is runtime suspended,
      and I agree that's a good argument, but I still think that the reason
      explained in the first paragraph already justifies the patch.
      This problem can easily be reproduced with many subtests of
      igt/pm_rpm, and it is a regression introduced by:
      
          commit c5ad011d
          Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
          Date:   Mon Aug 4 03:51:38 2014 -0700
              drm/i915: FBC flush nuke for BDW
      
      Testcase: igt/pm_rpm/cursor (and others)
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9adccc60
  8. 19 9月, 2014 4 次提交
  9. 12 9月, 2014 1 次提交
  10. 08 9月, 2014 1 次提交
    • C
      drm/i915: Prevent recursive deadlock on releasing a busy userptr · ad46cb53
      Chris Wilson 提交于
      During release of the GEM object we hold the struct_mutex. As the
      object may be holding onto the last reference for the task->mm,
      calling mmput() may trigger exit_mmap() which close the vma
      which will call drm_gem_vm_close() and attempt to reacquire
      the struct_mutex. In order to avoid that recursion, we have
      to defer the mmput() until after we drop the struct_mutex,
      i.e. we need to schedule a worker to do the clean up. A further issue
      spotted by Tvrtko was caused when we took a GTT mmapping of a userptr
      buffer object. In that case, we would never call mmput as the object
      would be cyclically referenced by the GTT mmapping and not freed upon
      process exit - keeping the entire process mm alive after the process
      task was reaped. The fix employed is to replace the mm_users/mmput()
      reference handling to mm_count/mmdrop() for the shared i915_mm_struct.
      
         INFO: task test_surfaces:1632 blocked for more than 120 seconds.
               Tainted: GF          O 3.14.5+ #1
         "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
         test_surfaces   D 0000000000000000     0  1632   1590 0x00000082
          ffff88014914baa8 0000000000000046 0000000000000000 ffff88014914a010
          0000000000012c40 0000000000012c40 ffff8800a0058210 ffff88014784b010
          ffff88014914a010 ffff880037b1c820 ffff8800a0058210 ffff880037b1c824
         Call Trace:
          [<ffffffff81582499>] schedule+0x29/0x70
          [<ffffffff815825fe>] schedule_preempt_disabled+0xe/0x10
          [<ffffffff81583b93>] __mutex_lock_slowpath+0x183/0x220
          [<ffffffff81583c53>] mutex_lock+0x23/0x40
          [<ffffffffa005c2a3>] drm_gem_vm_close+0x33/0x70 [drm]
          [<ffffffff8115a483>] remove_vma+0x33/0x70
          [<ffffffff8115a5dc>] exit_mmap+0x11c/0x170
          [<ffffffff8104d6eb>] mmput+0x6b/0x100
          [<ffffffffa00f44b9>] i915_gem_userptr_release+0x89/0xc0 [i915]
          [<ffffffffa00e6706>] i915_gem_free_object+0x126/0x250 [i915]
          [<ffffffffa005c06a>] drm_gem_object_free+0x2a/0x40 [drm]
          [<ffffffffa005cc32>] drm_gem_object_handle_unreference_unlocked+0xe2/0x120 [drm]
          [<ffffffffa005ccd4>] drm_gem_object_release_handle+0x64/0x90 [drm]
          [<ffffffff8127ffeb>] idr_for_each+0xab/0x100
          [<ffffffffa005cc70>] ?  drm_gem_object_handle_unreference_unlocked+0x120/0x120 [drm]
          [<ffffffff81583c46>] ? mutex_lock+0x16/0x40
          [<ffffffffa005c354>] drm_gem_release+0x24/0x40 [drm]
          [<ffffffffa005b82b>] drm_release+0x3fb/0x480 [drm]
          [<ffffffff8118d482>] __fput+0xb2/0x260
          [<ffffffff8118d6de>] ____fput+0xe/0x10
          [<ffffffff8106f27f>] task_work_run+0x8f/0xf0
          [<ffffffff81052228>] do_exit+0x1a8/0x480
          [<ffffffff81052551>] do_group_exit+0x51/0xc0
          [<ffffffff810525d7>] SyS_exit_group+0x17/0x20
          [<ffffffff8158e092>] system_call_fastpath+0x16/0x1b
      
      v2: Incorporate feedback from Tvrtko and remove the unnessary mm
      referencing when creating the i915_mm_struct and improve some of the
      function names and comments.
      Reported-by: NJacek Danecki <jacek.danecki@intel.com>
      Test-case: igt/gem_userptr_blits/process-exit*
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: N"Gong, Zhipeng" <zhipeng.gong@intel.com>
      Cc: Jacek Danecki <jacek.danecki@intel.com>
      Cc: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
      Reviewed-by: N"Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org # hold off until 3.17 ships for additional testing
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      ad46cb53
  11. 05 9月, 2014 1 次提交
  12. 04 9月, 2014 2 次提交
  13. 03 9月, 2014 10 次提交
  14. 23 8月, 2014 1 次提交
  15. 20 8月, 2014 1 次提交