1. 29 10月, 2021 2 次提交
    • U
      drm/i915/pmu: Connect engine busyness stats from GuC to pmu · 77cdd054
      Umesh Nerlige Ramappa 提交于
      With GuC handling scheduling, i915 is not aware of the time that a
      context is scheduled in and out of the engine. Since i915 pmu relies on
      this info to provide engine busyness to the user, GuC shares this info
      with i915 for all engines using shared memory. For each engine, this
      info contains:
      
      - total busyness: total time that the context was running (total)
      - id: id of the running context (id)
      - start timestamp: timestamp when the context started running (start)
      
      At the time (now) of sampling the engine busyness, if the id is valid
      (!= ~0), and start is non-zero, then the context is considered to be
      active and the engine busyness is calculated using the below equation
      
      	engine busyness = total + (now - start)
      
      All times are obtained from the gt clock base. For inactive contexts,
      engine busyness is just equal to the total.
      
      The start and total values provided by GuC are 32 bits and wrap around
      in a few minutes. Since perf pmu provides busyness as 64 bit
      monotonically increasing values, there is a need for this implementation
      to account for overflows and extend the time to 64 bits before returning
      busyness to the user. In order to do that, a worker runs periodically at
      frequency = 1/8th the time it takes for the timestamp to wrap. As an
      example, that would be once in 27 seconds for a gt clock frequency of
      19.2 MHz.
      
      Note:
      There might be an over-accounting of busyness due to the fact that GuC
      may be updating the total and start values while kmd is reading them.
      (i.e kmd may read the updated total and the stale start). In such a
      case, user may see higher busyness value followed by smaller ones which
      would eventually catch up to the higher value.
      
      v2: (Tvrtko)
      - Include details in commit message
      - Move intel engine busyness function into execlist code
      - Use union inside engine->stats
      - Use natural type for ping delay jiffies
      - Drop active_work condition checks
      - Use for_each_engine if iterating all engines
      - Drop seq locking, use spinlock at GuC level to update engine stats
      - Document worker specific details
      
      v3: (Tvrtko/Umesh)
      - Demarcate GuC and execlist stat objects with comments
      - Document known over-accounting issue in commit
      - Provide a consistent view of GuC state
      - Add hooks to gt park/unpark for GuC busyness
      - Stop/start worker in gt park/unpark path
      - Drop inline
      - Move spinlock and worker inits to GuC initialization
      - Drop helpers that are called only once
      
      v4: (Tvrtko/Matt/Umesh)
      - Drop addressed opens from commit message
      - Get runtime pm in ping, remove from the park path
      - Use cancel_delayed_work_sync in disable_submission path
      - Update stats during reset prepare
      - Skip ping if reset in progress
      - Explicitly name execlists and GuC stats objects
      - Since disable_submission is called from many places, move resetting
        stats to intel_guc_submission_reset_prepare
      
      v5: (Tvrtko)
      - Add a trylock helper that does not sleep and synchronize PMU event
        callbacks and worker with gt reset
      
      v6: (CI BAT failures)
      - DUTs using execlist submission failed to boot since __gt_unpark is
        called during i915 load. This ends up calling the GuC busyness unpark
        hook and results in kick-starting an uninitialized worker. Let
        park/unpark hooks check if GuC submission has been initialized.
      - drop cant_sleep() from trylock helper since rcu_read_lock takes care
        of that.
      
      v7: (CI) Fix igt@i915_selftest@live@gt_engines
      - For GuC mode of submission the engine busyness is derived from gt time
        domain. Use gt time elapsed as reference in the selftest.
      - Increase busyness calculation to 10ms duration to ensure batch runs
        longer and falls within the busyness tolerances in selftest.
      
      v8:
      - Use ktime_get in selftest as before
      - intel_reset_trylock_no_wait results in a lockdep splat that is not
        trivial to fix since the PMU callback runs in irq context and the
        reset paths are tightly knit into the driver. The test that uncovers
        this is igt@perf_pmu@faulting-read. Drop intel_reset_trylock_no_wait,
        instead use the reset_count to synchronize with gt reset during pmu
        callback. For the ping, continue to use intel_reset_trylock since ping
        is not run in irq context.
      
      - GuC PM timestamp does not tick when GuC is idle. This can potentially
        result in wrong busyness values when a context is active on the
        engine, but GuC is idle. Use the RING TIMESTAMP as GPU timestamp to
        process the GuC busyness stats. This works since both GuC timestamp and
        RING timestamp are synced with the same clock.
      
      - The busyness stats may get updated after the batch starts running.
        This delay causes the busyness reported for 100us duration to fall
        below 95% in the selftest. The only option at this time is to wait for
        GuC busyness to change from idle to active before we sample busyness
        over a 100us period.
      Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
      Signed-off-by: NUmesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
      Acked-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NMatthew Brost <matthew.brost@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20211027004821.66097-2-umesh.nerlige.ramappa@intel.com
      77cdd054
    • U
      drm/i915/pmu: Add a name to the execlists stats · 344e6947
      Umesh Nerlige Ramappa 提交于
      In preparation for GuC pmu stats, add a name to the execlists stats
      structure so that it can be differentiated from the GuC stats.
      Signed-off-by: NUmesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
      Reviewed-by: NMatthew Brost <matthew.brost@intel.com>
      Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20211027004821.66097-1-umesh.nerlige.ramappa@intel.com
      344e6947
  2. 16 10月, 2021 2 次提交
  3. 24 9月, 2021 1 次提交
    • T
      drm/i915/gt: Register the migrate contexts with their engines · 3e42cc61
      Thomas Hellström 提交于
      Pinned contexts, like the migrate contexts need reset after resume
      since their context image may have been lost. Also the GuC needs to
      register pinned contexts.
      
      Add a list to struct intel_engine_cs where we add all pinned contexts on
      creation, and traverse that list at resume time to reset the pinned
      contexts.
      
      This fixes the kms_pipe_crc_basic@suspend-read-crc-pipe-a selftest for now,
      but proper LMEM backup / restore is needed for full suspend functionality.
      However, note that even with full LMEM backup / restore it may be
      desirable to keep the reset since backing up the migrate context images
      must happen using memcpy() after the migrate context has become inactive,
      and for performance- and other reasons we want to avoid memcpy() from
      LMEM.
      
      Also traverse the list at guc_init_lrc_mapping() calling
      guc_kernel_context_pin() for the pinned contexts, like is already done
      for the kernel context.
      
      v2:
      - Don't reset the contexts on each __engine_unpark() but rather at
        resume time (Chris Wilson).
      v3:
      - Reset contexts in the engine sanitize callback. (Chris Wilson)
      
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Brost Matthew <matthew.brost@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NThomas Hellström <thomas.hellstrom@linux.intel.com>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210922062527.865433-6-thomas.hellstrom@linux.intel.com
      3e42cc61
  4. 21 9月, 2021 1 次提交
  5. 11 8月, 2021 2 次提交
  6. 30 7月, 2021 1 次提交
  7. 28 7月, 2021 4 次提交
  8. 26 7月, 2021 1 次提交
  9. 24 7月, 2021 1 次提交
  10. 23 7月, 2021 4 次提交
  11. 09 7月, 2021 1 次提交
  12. 07 7月, 2021 1 次提交
    • T
      drm/i915: Use the correct IRQ during resume · 320ad343
      Thomas Zimmermann 提交于
      The code in xcs_resume() probably didn't work as intended. It uses
      struct drm_device.irq, which is allocated to 0, but never initialized
      by i915 to the device's interrupt number.
      
      Change all calls to synchronize_hardirq() to intel_synchronize_irq(),
      which uses the correct interrupt. _hardirq() functions are not needed
      in this context.
      
      v5:
      	* go back to _hardirq() after PCI probe reported wrong
      	  context; add rsp comment
      v4:
      	* switch everything to intel_synchronize_irq() (Daniel)
      v3:
      	* also use intel_synchronize_hardirq() at another callsite
      v2:
      	* wrap irq code in intel_synchronize_hardirq() (Ville)
      Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
      Fixes: 536f77b1 ("drm/i915/gt: Call stop_ring() from ring resume, again")
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Lucas De Marchi <lucas.demarchi@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210701173618.10718-2-tzimmermann@suse.de
      (cherry picked from commit 27e4b467)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      320ad343
  13. 03 7月, 2021 1 次提交
    • T
      drm/i915: Use the correct IRQ during resume · 27e4b467
      Thomas Zimmermann 提交于
      The code in xcs_resume() probably didn't work as intended. It uses
      struct drm_device.irq, which is allocated to 0, but never initialized
      by i915 to the device's interrupt number.
      
      Change all calls to synchronize_hardirq() to intel_synchronize_irq(),
      which uses the correct interrupt. _hardirq() functions are not needed
      in this context.
      
      v5:
      	* go back to _hardirq() after PCI probe reported wrong
      	  context; add rsp comment
      v4:
      	* switch everything to intel_synchronize_irq() (Daniel)
      v3:
      	* also use intel_synchronize_hardirq() at another callsite
      v2:
      	* wrap irq code in intel_synchronize_hardirq() (Ville)
      Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
      Fixes: 536f77b1 ("drm/i915/gt: Call stop_ring() from ring resume, again")
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Lucas De Marchi <lucas.demarchi@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210701173618.10718-2-tzimmermann@suse.de
      27e4b467
  14. 19 6月, 2021 5 次提交
  15. 18 6月, 2021 1 次提交
  16. 17 6月, 2021 1 次提交
  17. 06 6月, 2021 1 次提交
  18. 04 6月, 2021 1 次提交
  19. 25 5月, 2021 2 次提交
  20. 10 5月, 2021 1 次提交
  21. 14 4月, 2021 1 次提交
  22. 25 3月, 2021 4 次提交
  23. 24 3月, 2021 1 次提交
    • M
      drm/i915: Do not share hwsp across contexts any more, v8. · 12ca695d
      Maarten Lankhorst 提交于
      Instead of sharing pages with breadcrumbs, give each timeline a
      single page. This allows unrelated timelines not to share locks
      any more during command submission.
      
      As an additional benefit, seqno wraparound no longer requires
      i915_vma_pin, which means we no longer need to worry about a
      potential -EDEADLK at a point where we are ready to submit.
      
      Changes since v1:
      - Fix erroneous i915_vma_acquire that should be a i915_vma_release (ickle).
      - Extra check for completion in intel_read_hwsp().
      Changes since v2:
      - Fix inconsistent indent in hwsp_alloc() (kbuild)
      - memset entire cacheline to 0.
      Changes since v3:
      - Do same in intel_timeline_reset_seqno(), and clflush for good measure.
      Changes since v4:
      - Use refcounting on timeline, instead of relying on i915_active.
      - Fix waiting on kernel requests.
      Changes since v5:
      - Bump amount of slots to maximum (256), for best wraparounds.
      - Add hwsp_offset to i915_request to fix potential wraparound hang.
      - Ensure timeline wrap test works with the changes.
      - Assign hwsp in intel_timeline_read_hwsp() within the rcu lock to
        fix a hang.
      Changes since v6:
      - Rename i915_request_active_offset to i915_request_active_seqno(),
        and elaborate the function. (tvrtko)
      Changes since v7:
      - Move hunk to where it belongs. (jekstrand)
      - Replace CACHELINE_BYTES with TIMELINE_SEQNO_BYTES. (jekstrand)
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com> #v1
      Reported-by: Nkernel test robot <lkp@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210323155059.628690-2-maarten.lankhorst@linux.intel.com
      12ca695d