1. 13 10月, 2014 2 次提交
    • A
      Revert "drm/radeon: drop btc_get_max_clock_from_voltage_dependency_table" · 60779143
      Alex Deucher 提交于
      This reverts commit fc9dfeb1.
      
      There are still some stability problems on some SI boards so bring
      this back.
      60779143
    • D
      drm/mst: rework payload table allocation to conform better. · dfda0df3
      Dave Airlie 提交于
      The old code has problems with the Dell MST monitors due to some
      assumptions I made that weren't true.
      
      I initially thought the Virtual Channel Payload IDs had to be in
      the DPCD table in ascending order, however it appears that assumption
      is bogus.
      
      The old code also assumed it was possible to insert a member
      into the table and it would move other members up, like it does
      when you remove table entries, however reality has shown this
      isn't true.
      
      So the new code allocates VCPIs separate from entries in the payload
      tracking table, and when we remove an entry from the DPCD table,
      I shuffle the tracking payload entries around in the struct.
      
      This appears to make VT switch more robust (still not perfect)
      with an MST enabled Dell monitor.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      dfda0df3
  2. 08 10月, 2014 1 次提交
  3. 03 10月, 2014 6 次提交
  4. 01 10月, 2014 18 次提交
  5. 30 9月, 2014 6 次提交
  6. 29 9月, 2014 4 次提交
    • V
      drm/i915: Don't spam dmesg with rps messages on vlv/chv · 67956867
      Ville Syrjälä 提交于
      If the GPU frequency isn't going to change don't spam dmesg with
      debug messages about it.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      67956867
    • T
      drm/i915: Do not leak pages when freeing userptr objects · c479f438
      Tvrtko Ursulin 提交于
      sg_alloc_table_from_pages() can build us a table with coalesced ranges which
      means we need to iterate over pages and not sg table entries when releasing
      page references.
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: "Barbalho, Rafael" <rafael.barbalho@intel.com>
      Tested-by: NRafael Barbalho <rafael.barbalho@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      [danvet: Remove unused local variable sg.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      c479f438
    • C
      drm/i915: Do not store the error pointer for a failed userptr registration · e9681366
      Chris Wilson 提交于
      If we fail to create our mmu notification, we report the error back and
      currently store the error inside the i915_mm_struct. This not only causes
      subsequent registerations of the same mm to fail (an issue if the first
      was interrupted by a signal and needed to be restarted) but also causes
      us to eventually try and free the error pointer.
      
      [   73.419599] BUG: unable to handle kernel NULL pointer dereference at 000000000000004c
      [   73.419831] IP: [<ffffffff8114af33>] mmu_notifier_unregister+0x23/0x130
      [   73.420065] PGD 8650c067 PUD 870bb067 PMD 0
      [   73.420319] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      [   73.420580] CPU: 0 PID: 42 Comm: kworker/0:1 Tainted: G        W      3.17.0-rc6+ #1561
      [   73.420837] Hardware name: Intel Corporation SandyBridge Platform/LosLunas CRB, BIOS ASNBCPT1.86C.0075.P00.1106281639 06/28/2011
      [   73.421405] Workqueue: events __i915_mm_struct_free__worker
      [   73.421724] task: ffff880088a81220 ti: ffff880088168000 task.ti: ffff880088168000
      [   73.422051] RIP: 0010:[<ffffffff8114af33>]  [<ffffffff8114af33>] mmu_notifier_unregister+0x23/0x130
      [   73.422410] RSP: 0018:ffff88008816bd50  EFLAGS: 00010286
      [   73.422765] RAX: 0000000000000003 RBX: ffff880086485400 RCX: 0000000000000000
      [   73.423137] RDX: ffff88016d80ee90 RSI: ffff880086485400 RDI: 0000000000000044
      [   73.423513] RBP: ffff88008816bd70 R08: 0000000000000001 R09: 0000000000000000
      [   73.423895] R10: 0000000000000320 R11: 0000000000000001 R12: 0000000000000044
      [   73.424282] R13: ffff880166e5f008 R14: ffff88016d815200 R15: ffff880166e5f040
      [   73.424682] FS:  0000000000000000(0000) GS:ffff88016d800000(0000) knlGS:0000000000000000
      [   73.425099] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   73.425537] CR2: 000000000000004c CR3: 0000000087f5f000 CR4: 00000000000407f0
      [   73.426157] Stack:
      [   73.426597]  ffff880088a81248 ffff880166e5f038 fffffffffffffffc ffff880166e5f008
      [   73.427096]  ffff88008816bd98 ffffffff814a75f2 ffff880166e5f038 ffff8800880f8a28
      [   73.427603]  ffff88016d812ac0 ffff88008816be00 ffffffff8106321a ffffffff810631af
      [   73.428119] Call Trace:
      [   73.428606]  [<ffffffff814a75f2>] __i915_mm_struct_free__worker+0x42/0x80
      [   73.429116]  [<ffffffff8106321a>] process_one_work+0x1ba/0x610
      [   73.429632]  [<ffffffff810631af>] ? process_one_work+0x14f/0x610
      [   73.430153]  [<ffffffff810636db>] worker_thread+0x6b/0x4a0
      [   73.430671]  [<ffffffff8108d67d>] ? trace_hardirqs_on+0xd/0x10
      [   73.431501]  [<ffffffff81063670>] ? process_one_work+0x610/0x610
      [   73.432030]  [<ffffffff8106a206>] kthread+0xf6/0x110
      [   73.432561]  [<ffffffff8106a110>] ? __kthread_parkme+0x80/0x80
      [   73.433100]  [<ffffffff8169c22c>] ret_from_fork+0x7c/0xb0
      [   73.433644]  [<ffffffff8106a110>] ? __kthread_parkme+0x80/0x80
      [   73.434194] Code: 0f 1f 84 00 00 00 00 00 66 66 66 66 90 8b 46 4c 85 c0 0f 8e 10 01 00 00 55 48 89 e5 41 55 41 54 53 48 89 f3 49 89 fc 48 83 ec 08 <48> 83 7f 08 00 0f 84 b1 00 00 00 48 c7 c7 40 e6 ac 82 e8 26 65
      [   73.435942] RIP  [<ffffffff8114af33>] mmu_notifier_unregister+0x23/0x130
      [   73.437017]  RSP <ffff88008816bd50>
      [   73.437704] CR2: 000000000000004c
      
      Fixes regression from commit ad46cb53
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Aug 7 14:20:40 2014 +0100
      
          drm/i915: Prevent recursive deadlock on releasing a busy userptr
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84207
      Testcase: igt/gem_render_copy_redux
      Testcase: igt/gem_userptr_blits/create-destroy-sync
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Jacek Danecki <jacek.danecki@intel.com>
      Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
      Cc: Jacek Danecki <jacek.danecki@intel.com>
      Cc: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      e9681366
    • 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
  7. 25 9月, 2014 2 次提交
  8. 24 9月, 2014 1 次提交