Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 29 10月, 2020 1 次提交
  3. 10 12月, 2019 2 次提交
    • D
      drm/i915/guc: kill the GuC client · 3c9abe88
      由 Daniele Ceraolo Spurio 提交于 
      We now only use 1 client without any plan to add more. The client is
also only holding information about the WQ and the process desc, so we
can just move those in the intel_guc structure and always use stage_id
0.

v2: fix comment (John)
v3: fix the comment for real, fix kerneldoc
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: NJohn Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205220243.27403-4-daniele.ceraolospurio@intel.com
      3c9abe88
    • D
      drm/i915/guc: kill doorbell code and selftests · e9362e13
      由 Daniele Ceraolo Spurio 提交于 
      Instead of relying on the workqueue, the upcoming reworked GuC
submission flow will offer the host driver indipendent control over
the execution status of each context submitted to GuC. As part of this,
the doorbell usage model has been reworked, with each doorbell being
paired to a single lrc and a doorbell ring representing new work
available for that specific context. This mechanism, however, limits
the number of contexts that can be registered with GuC to the number of
doorbells, which is an undesired limitation. To avoid this limitation,
we requested the GuC team to also provide a H2G that will allow the host
to notify the GuC of work available for a specified lrc, so we can use
that mechanism instead of relying on the doorbells. We can therefore drop
the doorbell code we currently have, also given the fact that in the
unlikely case we'd want to switch back to using doorbells we'd have to
heavily rework it.
The workqueue will still have a use in the new interface to pass special
commands, so that code has been retained for now.

With the doorbells gone and the GuC client becoming even simpler, the
existing GuC selftests don't give us any meaningful coverage so we can
remove them as well. Some selftests might come with the new code, but
they will look different from what we have now so if doesn't seem worth
it to keep the file around in the meantime.

v2: fix comments and commit message (John)
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: NJohn Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205220243.27403-3-daniele.ceraolospurio@intel.com
      e9362e13
  5. 24 10月, 2019 1 次提交
  7. 12 8月, 2019 1 次提交
  9. 26 7月, 2019 2 次提交
  11. 14 7月, 2019 1 次提交
  13. 04 7月, 2019 1 次提交
  15. 27 6月, 2019 1 次提交
  17. 06 6月, 2019 1 次提交
  19. 28 5月, 2019 2 次提交
  21. 23 10月, 2018 1 次提交
  23. 22 10月, 2018 1 次提交
  25. 18 10月, 2018 1 次提交
  27. 28 8月, 2018 1 次提交
  29. 12 6月, 2018 1 次提交
  31. 13 4月, 2018 1 次提交
  33. 29 3月, 2018 2 次提交
  35. 21 3月, 2018 1 次提交
  37. 19 3月, 2018 1 次提交
  39. 02 11月, 2017 1 次提交
    • M
      drm/i915/guc: Add support for reset engine using GuC commands · 6acbea89
      由 Michel Thierry 提交于 
      This patch adds per engine reset and recovery (TDR) support when GuC is
used to submit workloads to GPU.

In the case of i915 directly submission to ELSP, driver manages hang
detection, recovery and resubmission. With GuC submission these tasks
are shared between driver and GuC. i915 is still responsible for detecting
a hang, and when it does it only requests GuC to reset that Engine. GuC
internally manages acquiring forcewake and idling the engine before
resetting it.

Once the reset is successful, i915 takes over again and handles the
resubmission. The scheduler in i915 knows which requests are pending so
after resetting a engine, pending workloads/requests are resubmitted
again.

v2: s/i915_guc_request_engine_reset/i915_guc_reset_engine/ to match the
non-guc function names.

v3: Removed debug message about engine restarting from which request,
since the new baseline do it regardless of submission mode. (Chris)

v4: Rebase.

v5: Do not pass unnecessary reporting flags to the fw (Jeff);
tasklet_schedule(&execlists->irq_tasklet) handles the resubmit; rebase.

v6: Rename the existing reset engine function and share a similar
interface between guc and non-guc paths (Chris).
Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171031225309.10888-1-michel.thierry@intel.comReviewed-by: NJeff McGee <jeff.mcgee@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      6acbea89
  41. 27 10月, 2017 1 次提交
  43. 16 10月, 2017 1 次提交
  45. 06 10月, 2017 1 次提交
  47. 13 9月, 2017 2 次提交
  49. 26 5月, 2017 1 次提交
  51. 05 4月, 2017 1 次提交
  53. 23 3月, 2017 4 次提交
  55. 19 1月, 2017 1 次提交
    • A
      drm/i915/huc: Support HuC authentication · dac84a38
      由 Anusha Srivatsa 提交于 
      The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.

v2: rebased on top of drm-tip. Changed name format and upped
version 1.7.
v3: changed wait_for_atomic to wait_for
v4: rebased. Rename intel_huc_auh() to intel_guc_auth_huc()
and place the prototype in intel_guc.h,correct the comments.
v5: rebased. Moved intel_guc_auth_huc from i915_guc_submission.c
to intel_uc.c.Update dev to dev_priv in intel_guc_auth_huc().
Renamed HOST2GUC_ACTION_AUTHENTICATE_HUC TO INTEL_GUC_ACTION_
AUTHENTICATE_HUC
v6: rebased. Add newline on DRM_ERRORs that already dont have one.
v7: rebased. Replace wait_for with intel_wait_for_register() since
the latter employs sleep optimisations for quick responses- as pointed
out by Chris Wilson.
v8: rebased. Cleanup the intel_guc_auth_huc() by removing checks
already performed in earlier functions. Make comments more descriptive.
v9: rebased. Changed the bias for pinning the HuC object. Move
intel_guc_auth_huc() to intel_huc.c. Change DRM_DEBUGs to DRM_ERRORs
in intel_guc_auth_huc(). Add return status to DRM_ERRORs.
v10: Remove message not required for the user..

Cc: Chris Wilson <chris@chris-wilson.co.uk>
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>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484755558-1234-5-git-send-email-anusha.srivatsa@intel.com
      dac84a38
  57. 18 1月, 2017 1 次提交
  59. 07 12月, 2016 1 次提交
  61. 26 11月, 2016 1 次提交
  63. 25 10月, 2016 1 次提交
    • A
      drm/i915: Increase GuC log buffer size to reduce flush interrupts · 72c0bc66
      由 Akash Goel 提交于 
      In cases where GuC generate logs at a very high rate, correspondingly
the rate of flush interrupts is also very high.
So far total 8 pages were allocated for storing both ISR & DPC logs.
As per the half-full draining protocol followed by GuC, by doubling
the number of pages, the frequency of flush interrupts can be cut down
to almost half, which then helps in reducing the logging overhead.
So now allocating 8 pages apiece for ISR & DPC logs.
This also helps in reducing the output log file size, apart from
reducing the flush interrupt count. With the original settings,
44 KB was needed for one snapshot. With modified settings, 76 KB is
needed for a snapshot which will be equivalent to 2 snapshots of the
original setting. So 12KB saving, every 88 KB, over the original setting.
Suggested-by: NTvrtko Ursulin <tvrtko.ursulin@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>
      72c0bc66