1. 17 11月, 2016 2 次提交
  2. 15 11月, 2016 1 次提交
  3. 14 11月, 2016 1 次提交
  4. 11 11月, 2016 2 次提交
  5. 05 11月, 2016 2 次提交
    • L
      drm/i915: Reinit polling before hpd when resuming · e0b70061
      Lyude 提交于
      Now that we don't run the connector reprobing from i915_drm_resume(), we
      need to make it so we don't have to wait for reprobing to finish so that
      we actually speed things up. In order to do this, we need to make sure
      that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work()
      while trying to acquire the mode_config lock that
      drm_kms_helper_poll_enable() needs to acquire.
      
      The easiest way to do this is to just enable polling before hpd. This
      shouldn't break anything since at that point we have everything else we
      need for polling enabled.
      
      As well, this should result in a rather significant improvement in how
      quickly we can resume the system.
      Signed-off-by: NLyude <lyude@redhat.com>
      Tested-by: NDavid Weinehall <david.weinehall@linux.intel.com>
      Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
      Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915
      e0b70061
    • L
      drm/i915: Remove redundant reprobe in i915_drm_resume · f97f1936
      Lyude 提交于
      Weine's investigation on benchmarking the suspend/resume process pointed
      out a lot of the time in suspend/resume is being spent reprobing. While
      the reprobing process is a lengthy one for good reason, we don't need to
      hold up the entire suspend/resume process while we wait for it to
      finish. Luckily as it turns out, we already trigger a full connector
      reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
      i915_drm_resume() entirely.
      
      This won't lead to less time spent resuming just yet since now the
      bottleneck will be waiting for the mode_config lock in
      drm_kms_helper_poll_enable(), since that will be held as long as
      i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
      address that in the next patch.
      Signed-off-by: NLyude <lyude@redhat.com>
      Tested-by: NDavid Weinehall <david.weinehall@linux.intel.com>
      Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
      Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915
      f97f1936
  6. 02 11月, 2016 2 次提交
  7. 01 11月, 2016 4 次提交
    • V
    • V
      46f16e63
    • V
    • C
      drm/i915: Use the full hammer when shutting down the rcu tasks · 7d5d59e5
      Chris Wilson 提交于
      To flush all call_rcu() tasks (here from i915_gem_free_object()) we need
      to call rcu_barrier() (not synchronize_rcu()). If we don't then we may
      still have objects being freed as we continue to teardown the driver -
      in particular, the recently released rings may race with the memory
      manager shutdown resulting in sporadic:
      
      [  142.217186] WARNING: CPU: 7 PID: 6185 at drivers/gpu/drm/drm_mm.c:932 drm_mm_takedown+0x2e/0x40
      [  142.217187] Memory manager not clean during takedown.
      [  142.217187] Modules linked in: i915(-) x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel lpc_ich snd_hda_codec_realtek snd_hda_codec_generic mei_me mei snd_hda_codec_hdmi snd_hda_codec snd_hwdep snd_hda_core snd_pcm e1000e ptp pps_core [last unloaded: snd_hda_intel]
      [  142.217199] CPU: 7 PID: 6185 Comm: rmmod Not tainted 4.9.0-rc2-CI-Trybot_242+ #1
      [  142.217199] Hardware name: LENOVO 10AGS00601/SHARKBAY, BIOS FBKT34AUS 04/24/2013
      [  142.217200]  ffffc90002ecfce0 ffffffff8142dd65 ffffc90002ecfd30 0000000000000000
      [  142.217202]  ffffc90002ecfd20 ffffffff8107e4e6 000003a40778c2a8 ffff880401355c48
      [  142.217204]  ffff88040778c2a8 ffffffffa040f3c0 ffffffffa040f4a0 00005621fbf8b1f0
      [  142.217206] Call Trace:
      [  142.217209]  [<ffffffff8142dd65>] dump_stack+0x67/0x92
      [  142.217211]  [<ffffffff8107e4e6>] __warn+0xc6/0xe0
      [  142.217213]  [<ffffffff8107e54a>] warn_slowpath_fmt+0x4a/0x50
      [  142.217214]  [<ffffffff81559e3e>] drm_mm_takedown+0x2e/0x40
      [  142.217236]  [<ffffffffa035c02a>] i915_gem_cleanup_stolen+0x1a/0x20 [i915]
      [  142.217246]  [<ffffffffa034c581>] i915_ggtt_cleanup_hw+0x31/0xb0 [i915]
      [  142.217253]  [<ffffffffa0310311>] i915_driver_cleanup_hw+0x31/0x40 [i915]
      [  142.217260]  [<ffffffffa0312001>] i915_driver_unload+0x141/0x1a0 [i915]
      [  142.217268]  [<ffffffffa031c2c4>] i915_pci_remove+0x14/0x20 [i915]
      [  142.217269]  [<ffffffff8147d214>] pci_device_remove+0x34/0xb0
      [  142.217271]  [<ffffffff8157b14c>] __device_release_driver+0x9c/0x150
      [  142.217272]  [<ffffffff8157bcc6>] driver_detach+0xb6/0xc0
      [  142.217273]  [<ffffffff8157abe3>] bus_remove_driver+0x53/0xd0
      [  142.217274]  [<ffffffff8157c787>] driver_unregister+0x27/0x50
      [  142.217276]  [<ffffffff8147c265>] pci_unregister_driver+0x25/0x70
      [  142.217287]  [<ffffffffa03d764c>] i915_exit+0x1a/0x71 [i915]
      [  142.217289]  [<ffffffff811136b3>] SyS_delete_module+0x193/0x1e0
      [  142.217291]  [<ffffffff818174ae>] entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  142.217292] ---[ end trace 6fd164859c154772 ]---
      [  142.217505] [drm:show_leaks] *ERROR* node [6b6b6b6b6b6b6b6b + 6b6b6b6b6b6b6b6b]: inserted at
                      [<ffffffff81559ff3>] save_stack.isra.1+0x53/0xa0
                      [<ffffffff8155a98d>] drm_mm_insert_node_in_range_generic+0x2ad/0x360
                      [<ffffffffa035bf23>] i915_gem_stolen_insert_node_in_range+0x93/0xe0 [i915]
                      [<ffffffffa035c855>] i915_gem_object_create_stolen+0x75/0xb0 [i915]
                      [<ffffffffa036a51a>] intel_engine_create_ring+0x9a/0x140 [i915]
                      [<ffffffffa036a921>] intel_init_ring_buffer+0xf1/0x440 [i915]
                      [<ffffffffa036be1b>] intel_init_render_ring_buffer+0xab/0x1b0 [i915]
                      [<ffffffffa0363d08>] intel_engines_init+0xc8/0x210 [i915]
                      [<ffffffffa0355d7c>] i915_gem_init+0xac/0xf0 [i915]
                      [<ffffffffa0311454>] i915_driver_load+0x9c4/0x1430 [i915]
                      [<ffffffffa031c2f8>] i915_pci_probe+0x28/0x40 [i915]
                      [<ffffffff8147d315>] pci_device_probe+0x85/0xf0
                      [<ffffffff8157b7ff>] driver_probe_device+0x21f/0x430
                      [<ffffffff8157baee>] __driver_attach+0xde/0xe0
      
      In particular note that the node was being poisoned as we inspected the
      list, a  clear indication that the object is being freed as we make the
      assertion.
      
      v2: Don't loop, just assert that we do all the work required as that
      will be better at detecting further errors.
      
      Fixes: fbbd37b3 ("drm/i915: Move object release to a freelist + worker")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161101084843.3961-1-chris@chris-wilson.co.uk
      7d5d59e5
  8. 31 10月, 2016 1 次提交
  9. 29 10月, 2016 3 次提交
  10. 28 10月, 2016 1 次提交
  11. 25 10月, 2016 1 次提交
    • A
      drm/i915: Add a relay backed debugfs interface for capturing GuC logs · f8240835
      Akash Goel 提交于
      Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the
      User to capture GuC firmware logs. Availed relay framework to implement
      the interface, where Driver will have to just use a relay API to store
      snapshots of the GuC log buffer in the buffer managed by relay.
      The snapshot will be taken when GuC firmware sends a log buffer flush
      interrupt and up to four snapshots could be stored in the relay buffer.
      The relay buffer will be operated in a mode where it will overwrite the
      data not yet collected by User.
      Besides mmap method, through which User can directly access the relay
      buffer contents, relay also supports the 'poll' method. Through the 'poll'
      call on log file, User can come to know whenever a new snapshot of the
      log buffer is taken by Driver, so can run in tandem with the Driver and
      capture the logs in a sustained/streaming manner, without any loss of data.
      
      v2: Defer the creation of relay channel & associated debugfs file, as
          debugfs setup is now done at the end of i915 Driver load. (Chris)
      
      v3:
      - Switch to no-overwrite mode for relay.
      - Fix the relay sub buffer switching sequence.
      
      v4:
      - Update i915 Kconfig to select RELAY config. (TvrtKo)
      - Log a message when there is no sub buffer available to capture
        the GuC log buffer. (Tvrtko)
      - Increase the number of relay sub buffers to 8 from 4, to have
        sufficient buffering for boot time logs
      
      v5:
      - Fix the alignment, indentation issues and some minor cleanup. (Tvrtko)
      - Update the comment to elaborate on why a relay channel has to be
        associated with the debugfs file. (Tvrtko)
      
      v6:
      - Move the write to 'is_global' after the NULL check on parent directory
        dentry pointer. (Tvrtko)
      
      v7: Add a BUG_ON to validate relay buffer allocation size. (Chris)
      
      Testcase: igt/tools/intel_guc_logger
      Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NSourab Gupta <sourab.gupta@intel.com>
      Signed-off-by: NAkash Goel <akash.goel@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      f8240835
  12. 24 10月, 2016 2 次提交
  13. 19 10月, 2016 1 次提交
  14. 14 10月, 2016 10 次提交
  15. 13 10月, 2016 1 次提交
  16. 10 10月, 2016 2 次提交
    • 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
    • C
      drm/i915: Restore current RPS state after reset · ac756941
      Chris Wilson 提交于
      Following commit 821ed7df ("drm/i915: Update reset path to fix
      incomplete requests") we no longer mark the context as lost on reset as
      we keep the requests (and contexts) alive. However, RPS remains reset
      and we need to restore the current state to match the in-flight
      requests.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97824
      Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-1-chris@chris-wilson.co.uk
      (cherry picked from commit f2a91d1a)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      ac756941
  17. 05 10月, 2016 1 次提交
  18. 27 9月, 2016 1 次提交
  19. 21 9月, 2016 2 次提交
    • C
      drm/i915: Only shrink the unbound objects during freeze · 6a800eab
      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
      6a800eab
    • C
      drm/i915: Restore current RPS state after reset · f2a91d1a
      Chris Wilson 提交于
      Following commit 821ed7df ("drm/i915: Update reset path to fix
      incomplete requests") we no longer mark the context as lost on reset as
      we keep the requests (and contexts) alive. However, RPS remains reset
      and we need to restore the current state to match the in-flight
      requests.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97824
      Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-1-chris@chris-wilson.co.uk
      f2a91d1a