1. 18 10月, 2016 1 次提交
  2. 17 10月, 2016 3 次提交
  3. 14 10月, 2016 19 次提交
  4. 13 10月, 2016 1 次提交
  5. 12 10月, 2016 4 次提交
  6. 10 10月, 2016 4 次提交
    • C
      drm/i915: Unalias obj->phys_handle and obj->userptr · ca5732c5
      Chris Wilson 提交于
      We use obj->phys_handle to choose the pread/pwrite path, but as
      obj->phys_handle is a union with obj->userptr, we then mistakenly use
      the phys_handle path for userptr objects within pread/pwrite.
      
      Testcase: igt/gem_userptr_blits/forbidden-operations
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-2-chris@chris-wilson.co.uk
      (cherry picked from commit 5f12b80a)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      ca5732c5
    • P
      drm/i915: SAGV is not SKL-only, so rename a few things · 674f823b
      Paulo Zanoni 提交于
      The plan is to introduce intel_has_sagv() and then use it to discover
      which platforms actually support it.
      
      I thought about keeping the functions with their current skl names,
      but found two problems: (i) skl_has_sagv() would become a very
      confusing name, and (ii) intel_atomic_commit_tail() doesn't seem to be
      calling any functions whose name start with a platform name, so the
      "intel_" naming scheme seems make more sense than the "firstplatorm_"
      naming scheme here.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: NLyude <cpaul@redhat.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-2-git-send-email-paulo.r.zanoni@intel.com
      (cherry picked from commit 16dcdc4e)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      674f823b
    • C
      drm/i915: Only shrink the unbound objects during freeze · ec7ce653
      Chris Wilson 提交于
      At the point of creating the hibernation image, the runtime power manage
      core is disabled - and using the rpm functions triggers a warn.
      i915_gem_shrink_all() tries to unbind objects, which requires device
      access and so tries to how an rpm reference triggering a warning:
      
      [   44.235420] ------------[ cut here ]------------
      [   44.235424] WARNING: CPU: 2 PID: 2199 at drivers/gpu/drm/i915/intel_runtime_pm.c:2688 intel_runtime_pm_get_if_in_use+0xe6/0xf0
      [   44.235426] WARN_ON_ONCE(ret < 0)
      [   44.235445] Modules linked in: ctr ccm arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt mac80211 cmac cfg80211 btusb rfcomm bnep btrtl btbcm btintel bluetooth dcdbas x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic aesni_intel snd_hda_codec_hdmi aes_x86_64 lrw gf128mul snd_hda_intel glue_helper ablk_helper cryptd snd_hda_codec hid_multitouch joydev snd_hda_core binfmt_misc i2c_hid serio_raw snd_pcm acpi_pad snd_timer snd i2c_designware_platform 8250_dw nls_iso8859_1 i2c_designware_core lpc_ich mfd_core soundcore usbhid hid psmouse ahci libahci
      [   44.235447] CPU: 2 PID: 2199 Comm: kworker/u8:8 Not tainted 4.8.0-rc5+ #130
      [   44.235447] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015
      [   44.235450] Workqueue: events_unbound async_run_entry_fn
      [   44.235453]  0000000000000000 ffff8801b2f7fb98 ffffffff81306c2f ffff8801b2f7fbe8
      [   44.235454]  0000000000000000 ffff8801b2f7fbd8 ffffffff81056c01 00000a801f50ecc0
      [   44.235456]  ffff88020ce50000 ffff88020ce59b60 ffffffff81a60b5c ffffffff81414840
      [   44.235456] Call Trace:
      [   44.235459]  [<ffffffff81306c2f>] dump_stack+0x4d/0x6e
      [   44.235461]  [<ffffffff81056c01>] __warn+0xd1/0xf0
      [   44.235464]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
      [   44.235465]  [<ffffffff81056c6f>] warn_slowpath_fmt+0x4f/0x60
      [   44.235468]  [<ffffffff814e73ce>] ? pm_runtime_get_if_in_use+0x6e/0xa0
      [   44.235469]  [<ffffffff81433526>] intel_runtime_pm_get_if_in_use+0xe6/0xf0
      [   44.235471]  [<ffffffff81458a26>] i915_gem_shrink+0x306/0x360
      [   44.235473]  [<ffffffff81343fd4>] ? pci_platform_power_transition+0x24/0x90
      [   44.235475]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
      [   44.235476]  [<ffffffff81458dfb>] i915_gem_shrink_all+0x1b/0x30
      [   44.235478]  [<ffffffff814560b3>] i915_gem_freeze_late+0x33/0x90
      [   44.235479]  [<ffffffff81414877>] i915_pm_freeze_late+0x37/0x40
      [   44.235481]  [<ffffffff814e9b8e>] dpm_run_callback+0x4e/0x130
      [   44.235483]  [<ffffffff814ea5db>] __device_suspend_late+0xdb/0x1f0
      [   44.235484]  [<ffffffff814ea70f>] async_suspend_late+0x1f/0xa0
      [   44.235486]  [<ffffffff81077557>] async_run_entry_fn+0x37/0x150
      [   44.235488]  [<ffffffff8106f518>] process_one_work+0x148/0x3f0
      [   44.235490]  [<ffffffff8106f8eb>] worker_thread+0x12b/0x490
      [   44.235491]  [<ffffffff8106f7c0>] ? process_one_work+0x3f0/0x3f0
      [   44.235492]  [<ffffffff81074d09>] kthread+0xc9/0xe0
      [   44.235495]  [<ffffffff816e257f>] ret_from_fork+0x1f/0x40
      [   44.235496]  [<ffffffff81074c40>] ? kthread_park+0x60/0x60
      [   44.235497] ---[ end trace e438706b97c7f132 ]---
      
      Alternatively, to actually shrink everything we have to do so slightly
      earlier in the hibernation process.
      
      To keep lockdep silent, we need to take struct_mutex for the shrinker
      even though we know that we are the only user during the freeze.
      
      Fixes: 7aab2d53 ("drm/i915: Shrink objects prior to hibernation")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-2-chris@chris-wilson.co.uk
      (cherry picked from commit 6a800eab)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      ec7ce653
    • D
      drm/i915: Update DRIVER_DATE to 20161010 · 738bb80e
      Daniel Vetter 提交于
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      738bb80e
  7. 05 10月, 2016 3 次提交
  8. 04 10月, 2016 3 次提交
  9. 27 9月, 2016 1 次提交
  10. 23 9月, 2016 1 次提交
    • P
      drm/i915/fbc: disable FBC on FIFO underruns · 61a585d6
      Paulo Zanoni 提交于
      Ever since I started working on FBC I was already aware that FBC can
      really amplify the FIFO underrun symptoms. On systems where FIFO
      underruns were harmless error messages, enabling FBC would cause the
      underruns to give black screens.
      
      We recently tried to enable FBC on Haswell and got reports of a system
      that would hang after some hours of uptime, and the first bad commit
      was the one that enabled FBC. We also observed that this system had
      FIFO underrun error messages on its dmesg. Although we don't have any
      evidence that fixing the underruns would solve the bug and make FBC
      work properly on this machine, IMHO it's better if we minimize the
      amount of possible problems by just giving up FBC whenever we detect
      an underrun.
      
      v2: New version, different implementation and commit message.
      v3: Clarify the fact that we run from an IRQ handler (Chris).
      v4: Also add the underrun_detected check at can_choose() to avoid
          misleading dmesg messages (DK).
      v5: Fix Engrish, use READ_ONCE on the unlocked read (Chris).
      
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: Lyude <cpaul@redhat.com>
      Cc: stevenhoneyman@gmail.com <stevenhoneyman@gmail.com>
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1473773937-19758-1-git-send-email-paulo.r.zanoni@intel.com
      61a585d6