1. 19 1月, 2017 2 次提交
    • A
      drm/i915/get_params: Add HuC status to getparams · 5464cd65
      Anusha Srivatsa 提交于
      This patch will allow for getparams to return the status of the HuC.
      As the HuC has to be validated by the GuC this patch uses the validated
      status to show when the HuC is loaded and ready for use. You cannot use
      the loaded status as with the GuC as the HuC is verified after it is
      loaded and is not usable until it is verified.
      
      v2: removed the forewakes as the registers are already force-woken.
           (T.Ursulin)
      v3: rebased on top of drm-tip. Removed any reference to intel_huc.h
      v4: rebased. Rename I915_PARAM_HAS_HUC to I915_PARAM_HUC_STATUS.
      Remove intel_is_huc_valid() since it is used only in one place.
      Put the case of I915_PARAM_HAS_HUC() in the right place.
      v5: rebased. Add a comment to specify that I915_READ(reg)
      does not read garbage value. The register HUC_STATUS2 is force
      woken and no rpm is needed.
      Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
      Signed-off-by: NPeter Antoine <peter.antoine@intel.com>
      Reviewed-by: NArkadiusz Hiler <arkadiusz.hiler@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1484755558-1234-6-git-send-email-anusha.srivatsa@intel.com
      5464cd65
    • A
      drm/i915/huc: Add HuC fw loading support · bd132858
      Anusha Srivatsa 提交于
      The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
      is used for both cases.
      
      HuC loading needs to be before GuC loading. The WOPCM setting must
      be done early before loading any of them.
      
      v2: rebased on-top of drm-intel-nightly.
          removed if(HAS_GUC()) before the guc call. (D.Gordon)
          update huc_version number of format.
      v3: rebased to drm-intel-nightly, changed the file name format to
          match the one in the huc package.
          Changed dev->dev_private to to_i915()
      v4: moved function back to where it was.
          change wait_for_atomic to wait_for.
      v5: rebased. Changed the year in the copyright message to reflect
      the right year.Correct the comments,remove the unwanted WARN message,
      replace drm_gem_object_unreference() with i915_gem_object_put().Make the
      prototypes in intel_huc.h non-extern.
      v6: rebased. Update the file construction done by HuC. It is similar to
      GuC.Adopted the approach used in-
      https://patchwork.freedesktop.org/patch/104355/ <Tvrtko Ursulin>
      v7: Change dev to dev_priv in macro definition.
      Corrected comments.
      v8: rebased on top of drm-tip. Updated functions intel_huc_load(),
      intel_huc_init() and intel_uc_fw_fetch() to accept dev_priv instead of
      dev. Moved contents of intel_huc.h to intel_uc.h.
      v9: change SKL_FW_ to SKL_HUC_FW_. Add intel_ prefix to guc_wopcm_size().
      Remove unwanted checks in intel_uc.h. Rename huc_fw in struct intel_huc to
      simply fw to avoid redundency.
      v10: rebased. Correct comments. Make intel_huc_fini() accept dev_priv
      instead of dev like intel_huc_init() and intel_huc_load().Move definition
      to i915_guc_reg.h from intel_uc.h. Clean DMA_CTRL bits after HuC DMA
      transfer in huc_ucode_xfer() instead of guc_ucode_xfer(). Add suitable
      WARNs to give extra info.
      v11: rebased. Add proper bias for HuC and make sure there are
      asserts on failure by using guc_ggtt_offset_vma(). Introduce
      intel_huc.c and remove intel_huc_loader.c since it has functions that
      do more than just loading.Correct year in copyright.
      v12: remove invalidates that are not required anymore.
      
      Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Tested-by: NXiang Haihao <haihao.xiang@intel.com>
      Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
      Signed-off-by: NAlex Dai <yu.dai@intel.com>
      Signed-off-by: NPeter Antoine <peter.antoine@intel.com>
      Reviewed-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1484755558-1234-1-git-send-email-anusha.srivatsa@intel.com
      bd132858
  2. 18 1月, 2017 3 次提交
  3. 12 1月, 2017 1 次提交
  4. 10 1月, 2017 2 次提交
  5. 05 1月, 2017 1 次提交
  6. 24 12月, 2016 1 次提交
  7. 08 12月, 2016 2 次提交
  8. 07 12月, 2016 2 次提交
  9. 02 12月, 2016 9 次提交
  10. 01 12月, 2016 2 次提交
  11. 26 11月, 2016 1 次提交
  12. 25 11月, 2016 1 次提交
  13. 23 11月, 2016 1 次提交
  14. 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
  15. 17 11月, 2016 3 次提交
  16. 15 11月, 2016 1 次提交
  17. 14 11月, 2016 1 次提交
  18. 11 11月, 2016 2 次提交
  19. 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
  20. 02 11月, 2016 1 次提交