summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_guc.h
diff options
context:
space:
mode:
authorDave Gordon <david.s.gordon@intel.com>2016-04-19 16:08:36 +0100
committerTvrtko Ursulin <tvrtko.ursulin@intel.com>2016-04-20 14:46:14 +0100
commit86e06cc0c0ecf3fdfe04ff48fccb34891767d514 (patch)
tree203eb19af627a5821bbd656704ec402fc26b52f7 /drivers/gpu/drm/i915/intel_guc.h
parenta5916e8f5406a48597971071b7cd94b688e72a9c (diff)
downloadop-kernel-dev-86e06cc0c0ecf3fdfe04ff48fccb34891767d514.zip
op-kernel-dev-86e06cc0c0ecf3fdfe04ff48fccb34891767d514.tar.gz
drm/i915/guc: local optimisations and updating comments
Tidying up guc_init_proc_desc() and adding commentary to the client structure after the recent change in GuC page mapping strategy. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461078516-28678-1-git-send-email-david.s.gordon@intel.com Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Diffstat (limited to 'drivers/gpu/drm/i915/intel_guc.h')
-rw-r--r--drivers/gpu/drm/i915/intel_guc.h23
1 files changed, 23 insertions, 0 deletions
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 19ca593..9d79c4c 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -29,6 +29,29 @@
struct drm_i915_gem_request;
+/*
+ * This structure primarily describes the GEM object shared with the GuC.
+ * The GEM object is held for the entire lifetime of our interaction with
+ * the GuC, being allocated before the GuC is loaded with its firmware.
+ * Because there's no way to update the address used by the GuC after
+ * initialisation, the shared object must stay pinned into the GGTT as
+ * long as the GuC is in use. We also keep the first page (only) mapped
+ * into kernel address space, as it includes shared data that must be
+ * updated on every request submission.
+ *
+ * The single GEM object described here is actually made up of several
+ * separate areas, as far as the GuC is concerned. The first page (kept
+ * kmap'd) includes the "process decriptor" which holds sequence data for
+ * the doorbell, and one cacheline which actually *is* the doorbell; a
+ * write to this will "ring the doorbell" (i.e. send an interrupt to the
+ * GuC). The subsequent pages of the client object constitute the work
+ * queue (a circular array of work items), again described in the process
+ * descriptor. Work queue pages are mapped momentarily as required.
+ *
+ * Finally, we also keep a few statistics here, including the number of
+ * submissions to each engine, and a record of the last submission failure
+ * (if any).
+ */
struct i915_guc_client {
struct drm_i915_gem_object *client_obj;
void *client_base; /* first page (only) of above */
OpenPOWER on IntegriCloud