- 21 Jun, 2019 40 commits
-
-
Chris Wilson authored
i915_gem_wait_for_idle() and i915_retire_requests() introduce a dependency on the timeline->mutex. This is problematic as we want to later perform allocations underneath i915_active.mutex, forming a link between the shrinker, the timeline and active mutexes. Nip this cycle in the bud by removing the acquisition of the timeline mutex (i.e. retiring) from inside the shrinker. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190621183801.23252-1-chris@chris-wilson.co.uk
-
Daniele Ceraolo Spurio authored
There is a very small chance of triggering a log flush event when enabling or disabling CT buffers. Events triggered while CT buffers are disabled are logged in the SCRATCH_15 register using the same bits used in the CT message payload. Since our communication channel with GuC is turned off, we can save the message and handle it after we turn it back on. GuC should be idle and not generate more events in the meantime because we're not talking to it. v2: clear the mmio register on stop_communication as well (Chris) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniele Ceraolo Spurio authored
Make sure we always have CT buffers enabled when the interrupts are enabled, so we can always handle interrupts from GuC. Also move the setting of the guc->send and guc->handler functions to the GuC communication control functions for consistency. The reorder also fixes the onion unwinding of intel_uc_init_hw, because guc_enable_communication would've left interrupts enabled when failing to enable CTB. v2: always retunr the result of ctch_enable() in intel_guc_ct_enable() (Michal) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110943Signed-off-by:Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/gt/intel_mocs.c:513: warning: Function parameter or member 'gt' not described in 'intel_mocs_init_l3cc_table' drivers/gpu/drm/i915/gt/intel_mocs.c:513: warning: Excess function parameter 'dev_priv' description in 'intel_mocs_init_l3cc_table' intel_vgt_balloon/deballoon, i915_ggtt_probe_hw intel_wopcm_init_hw need similar treatment Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190621131640.28864-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since the anonymous i915_gt became struct intel_gt and encloses struct i915_gt_timelines, rename i915_gt_timelines to intel_gt_timelines to match its parentage. Signed-off-by:
-
Chris Wilson authored
smatch caught, drivers/gpu/drm/i915/i915_gpu_error.c:1418 gem_record_rings() warn: variable dereferenced before check 'engine' (see line 1413) Signed-off-by:
-
Tvrtko Ursulin authored
Scratch vma lives under gt but the API used to work on i915. Make this consistent by renaming the function to intel_gt_scratch_offset and make it take struct intel_gt. v2: * Move to intel_gt. (Chris) Signed-off-by:
-
Tvrtko Ursulin authored
Move all timeline code under gt and rename to intel_gt prefix. Signed-off-by:
-
Tvrtko Ursulin authored
Our timelines are stored inside intel_gt so we can convert the interface to take exactly that and not i915. At the same time re-order the params to our more typical layout and replace the backpointer to the new containing structure. Signed-off-by:
-
Tvrtko Ursulin authored
For gt related operations it makes more logical sense to stay in the realm of gt instead of dereferencing via driver i915. This patch handles a few of the easy ones with work requiring more refactoring still outstanding. Signed-off-by:
-
Tvrtko Ursulin authored
Continuing on the theme of compartmentalizing the code better to make future split between gt and display in global i915 clearer. v2: * Pass in ggtt instead of gt. (Chris) Signed-off-by:
-
Tvrtko Ursulin authored
This will become useful in the following patch. v2: * Assign the pointer through a helper on the top level to work around the layering violation. (Chris) v3: * Handle selftests. v4: * Move call to intel_gt_init_hw into mock_init_ggtt. (Chris) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Continuing on the theme of better logical organization of our code, make the first step towards making the ggtt code better isolated from wider struct drm_i915_private. v2: * Bring the ickle onion unwind back. (Chris) * Rename to i915_init_ggtt. (Chris) Signed-off-by:
-
Tvrtko Ursulin authored
Continuing on the theme of better logical organization of our code, make the first step towards making the ggtt code better isolated from wider struct drm_i915_private. v2: * Cleanup of mm.wc_stash does not need struct_mutex. (Chris) Signed-off-by:
-
Tvrtko Ursulin authored
Continuing on the theme of better logical organization of our code, make the first step towards making the timeline code better isolated from wider struct drm_i915_private. Signed-off-by:
-
Tvrtko Ursulin authored
This aligns better with the rest of restructuring. v2: * Move call out of line. (Chris) Signed-off-by:
-
Tvrtko Ursulin authored
Having introduced struct intel_gt (named the anonymous structure in i915) we can start using it to compartmentalize our code better. It makes more sense logically to have the code internally like this and it will also help with future split between gt and display in i915. v2: * Keep ggtt flush before fb obj flush. (Chris) v3: * Fix refactoring fail. * Always flush ggtt writes. (Chris) Signed-off-by:
-
Tvrtko Ursulin authored
Having made start to better code compartmentalization by introducing struct intel_gt, continue the theme elsewhere in code by making functions take parameters take what logically makes most sense for them instead of the global struct drm_i915_private. Signed-off-by:
-
Tvrtko Ursulin authored
This will come useful in the following patch. v2: * Handle mock ggtt. Signed-off-by:
-
Tvrtko Ursulin authored
It is more logical for ggtt invalidation to take ggtt as input parameter. Signed-off-by:
-
Tvrtko Ursulin authored
Having made start to better code compartmentalization by introducing struct intel_gt, continue the theme elsewhere in code by making functions take parameters take what logically makes most sense for them instead of the global struct drm_i915_private. Signed-off-by:
-
Tvrtko Ursulin authored
Having made start to better code compartmentalization by introducing struct intel_gt, continue the theme elsewhere in code by making functions take parameters take what logically makes most sense for them instead of the global struct drm_i915_private. Signed-off-by:
-
Tvrtko Ursulin authored
More legacy mmio accessor removal. We pass in intel_gt explicitly allowing code to use new intel_uncore_read/write helpers. Signed-off-by:
-
Tvrtko Ursulin authored
Since this part still operates on i915 and not intel_gt, move it to the common (top-level) function. Signed-off-by:
-
Tvrtko Ursulin authored
More removal of implicit dev_priv from using old mmio accessors. Actually the top level function remains but is split into a part which writes to i915 and part which operates on intel_gt in order to initialize the hardware. GuC and engines are the only odd ones out remaining. Signed-off-by:
-
Tvrtko Ursulin authored
Replace some gen6/7 open coded rmw with intel_uncore_rmw. Signed-off-by:
-
Tvrtko Ursulin authored
More removal of implicit dev_priv from using old mmio accessors. v2: * Rebase for uncore_to_i915 removal. Signed-off-by:
-
Tvrtko Ursulin authored
More removal of implicit dev_priv from using old mmio accessors. Signed-off-by:
-
Tvrtko Ursulin authored
It will come useful in the next patch. v2: * Do mock_engine as well. v3: * And the virtual engine... Signed-off-by:
-
Tvrtko Ursulin authored
More conversion of i915_gem_init_hw to uncore. Signed-off-by:
-
Tvrtko Ursulin authored
More removal of implicit dev_priv from using old mmio accessors. Signed-off-by:
-
Tvrtko Ursulin authored
Two easy opportunities to compact the code by using the existing helper. Signed-off-by:
-
Tvrtko Ursulin authored
Start using the newly introduced struct intel_gt to fuse together correct logical init flow with uncore for more removal of implicit dev_priv in mmio access. v2: * Move code to i915_gem_fence_reg. (Chris) Signed-off-by:
-
Tvrtko Ursulin authored
Continuing the conversion and elimination of implicit dev_priv. Signed-off-by:
-
Tvrtko Ursulin authored
And also rename to intel_gt_pm_init_early and make it operate on gt. Signed-off-by:
-
Tvrtko Ursulin authored
We need an easy way to get back to i915 and uncore. Signed-off-by:
-
Tvrtko Ursulin authored
As it will grow in a following patch make a new home for it. v2: * Convert mock_gem_device as well. (Chris) v3: * Rename to intel_gt_init_early and move call site to i915_drv.c. (Chris) v4: * Adjust SPDX tags. * No need to gt/ path when including intel_gt_types.h. (Chris) Signed-off-by:
-
Tvrtko Ursulin authored
We have long been slighlty annoyed by the anonymous i915->gt. Promote it to a separate structure and give it its own header. This is a first step towards cleaning up the separation between i915 and gt. v2: * Adjust SPDX header. Signed-off-by:
-
Tvrtko Ursulin authored
More removal of implicit dev_priv from using old mmio accessors. Furthermore these calls really operate on ggtt so it logically makes sense if they take it as parameter. Signed-off-by:
-
Chris Wilson authored
The call to kick_siblings() dereferences the rq->context, so we should not drop our local reference until afterwards! v2: Stick to setting ce.inflight=NULL before kicking as this is what the other threads will check to see if the context is ready for takeover. Fixes: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by:
-
