1. 10 1月, 2017 1 次提交
  2. 05 1月, 2017 1 次提交
  3. 24 12月, 2016 1 次提交
  4. 08 12月, 2016 2 次提交
  5. 07 12月, 2016 2 次提交
  6. 02 12月, 2016 9 次提交
  7. 01 12月, 2016 2 次提交
  8. 26 11月, 2016 1 次提交
  9. 25 11月, 2016 1 次提交
  10. 23 11月, 2016 1 次提交
  11. 22 11月, 2016 2 次提交
    • R
      drm/i915: advertise available metrics via sysfs · 442b8c06
      Robert Bragg 提交于
      Each metric set is given a sysfs entry like:
      
      /sys/class/drm/card0/metrics/<guid>/id
      
      This allows userspace to enumerate the specific sets that are available
      for the current system. The 'id' file contains an unsigned integer that
      can be used to open the associated metric set via
      DRM_IOCTL_I915_PERF_OPEN. The <guid> is a globally unique ID for a
      specific OA unit register configuration that can be reliably used by
      userspace as a key to lookup corresponding counter meta data and
      normalization equations.
      
      The guid registry is currently maintained as part of gputop along with
      the XML metric set descriptions and code generation scripts, ref:
      
       https://github.com/rib/gputop
       > gputop-data/guids.xml
       > scripts/update-guids.py
       > gputop-data/oa-*.xml
       > scripts/i915-perf-kernelgen.py
      
       $ make -C gputop-data -f Makefile.xml SYSFS=1 WHITELIST=RenderBasic
      Signed-off-by: NRobert Bragg <robert@sixbynine.org>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Reviewed-by: NSourab Gupta <sourab.gupta@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-8-robert@sixbynine.org
      442b8c06
    • R
      drm/i915: Add i915 perf infrastructure · eec688e1
      Robert Bragg 提交于
      Adds base i915 perf infrastructure for Gen performance metrics.
      
      This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
      properties to configure a stream of metrics and returns a new fd usable
      with standard VFS system calls including read() to read typed and sized
      records; ioctl() to enable or disable capture and poll() to wait for
      data.
      
      A stream is opened something like:
      
        uint64_t properties[] = {
            /* Single context sampling */
            DRM_I915_PERF_PROP_CTX_HANDLE,        ctx_handle,
      
            /* Include OA reports in samples */
            DRM_I915_PERF_PROP_SAMPLE_OA,         true,
      
            /* OA unit configuration */
            DRM_I915_PERF_PROP_OA_METRICS_SET,    metrics_set_id,
            DRM_I915_PERF_PROP_OA_FORMAT,         report_format,
            DRM_I915_PERF_PROP_OA_EXPONENT,       period_exponent,
         };
         struct drm_i915_perf_open_param parm = {
            .flags = I915_PERF_FLAG_FD_CLOEXEC |
                     I915_PERF_FLAG_FD_NONBLOCK |
                     I915_PERF_FLAG_DISABLED,
            .properties_ptr = (uint64_t)properties,
            .num_properties = sizeof(properties) / 16,
         };
         int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, &param);
      
      Records read all start with a common { type, size } header with
      DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
      contain an extensible number of fields and it's the
      DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
      determine what's included in every sample.
      
      No specific streams are supported yet so any attempt to open a stream
      will return an error.
      
      v2:
          use i915_gem_context_get() - Chris Wilson
      v3:
          update read() interface to avoid passing state struct - Chris Wilson
          fix some rebase fallout, with i915-perf init/deinit
      v4:
          s/DRM_IORW/DRM_IOW/ - Emil Velikov
      Signed-off-by: NRobert Bragg <robert@sixbynine.org>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Reviewed-by: NSourab Gupta <sourab.gupta@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161107194957.3385-2-robert@sixbynine.org
      eec688e1
  12. 17 11月, 2016 3 次提交
  13. 15 11月, 2016 1 次提交
  14. 14 11月, 2016 1 次提交
  15. 11 11月, 2016 2 次提交
  16. 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
  17. 02 11月, 2016 2 次提交
  18. 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
  19. 31 10月, 2016 1 次提交
  20. 29 10月, 2016 1 次提交