- 21 Jun, 2019 31 commits
-
-
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 <tvrtko.ursulin@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190621070811.7006-30-tvrtko.ursulin@linux.intel.com
-
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:
-
- 20 Jun, 2019 9 commits
-
-
Chris Wilson authored
Enable RCU protection of i915_address_space and its ppgtt superclasses, and defer its cleanup into a worker executed after an RCU grace period. In the future we will be able to use the RCU protection to reduce the locking around VM lookups, but the immediate benefit is being able to defer the release into a kworker (process context). This is required as we may need to sleep to reap the WC pages stashed away inside the ppgtt. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110934Signed-off-by:
-
José Roberto de Souza authored
The other additional step in the DSI sequence for EHL. v2: - Using REG_BIT()(Matt) - Fixed commit message typo(Vandita) BSpec: 20597 Cc: Uma Shankar <uma.shankar@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619233134.20009-2-jose.souza@intel.com
-
Vandita Kulkarni authored
EHL has 2 additional steps in the DSI sequence, this is one of then the lane latency optimization for DW1. BSpec: 20597 Cc: Uma Shankar <uma.shankar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Chris Wilson authored
Since commit 79ffac85 ("drm/i915: Invert the GEM wakeref hierarchy"), the request creation itself took responsibility for managing the engine/GT wakerefs and so we can remove the redundant grabs in our selftests. References: 79ffac85 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by:
-
Chris Wilson authored
Our intel_rings are always flushed as they are continually used to submit commands to the GPU, and so do not need to be flushed on unpinning. This avoids pulling in the flush_ggtt_writes locking into our context unpin, which we want to allow from atomic context (for simplicity). Signed-off-by:
-
Chris Wilson authored
If we have multiple contexts of equal priority pending execution, activate a timer to demote the currently executing context in favour of the next in the queue when that timeslice expires. This enforces fairness between contexts (so long as they allow preemption -- forced preemption, in the future, will kick those who do not obey) and allows us to avoid userspace blocking forward progress with e.g. unbounded MI_SEMAPHORE_WAIT. For the starting point here, we use the jiffie as our timeslice so that we should be reasonably efficient wrt frequent CPU wakeups. Testcase: igt/gem_exec_scheduler/semaphore-resolve Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620142052.19311-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
When using a global seqno, we required a precise stop-the-workd event to handle preemption and unwind the global seqno counter. To accomplish this, we would preempt to a special out-of-band context and wait for the machine to report that it was idle. Given an idle machine, we could very precisely see which requests had completed and which we needed to feed back into the run queue. However, now that we have scrapped the global seqno, we no longer need to precisely unwind the global counter and only track requests by their per-context seqno. This allows us to loosely unwind inflight requests while scheduling a preemption, with the enormous caveat that the requests we put back on the run queue are still _inflight_ (until the preemption request is complete). This makes request tracking much more messy, as at any point then we can see a completed request that we believe is not currently scheduled for execution. We also have to be careful not to rewind RING_TAIL past RING_HEAD on preempting to the running context, and for this we use a semaphore to prevent completion of the request before continuing. To accomplish this feat, we change how we track requests scheduled to the HW. Instead of appending our requests onto a single list as we submit, we track each submission to ELSP as its own block. Then upon receiving the CS preemption event, we promote the pending block to the inflight block (discarding what was previously being tracked). As normal CS completion events arrive, we then remove stale entries from the inflight tracker. v2: Be a tinge paranoid and ensure we flush the write into the HWS page for the GPU semaphore to pick in a timely fashion. Signed-off-by:
-
Daniele Ceraolo Spurio authored
With multiple uncore to initialize (GT vs Display), it makes little sense to have the vgpu_check inside uncore_init(). We also have a catch-22 scenario where the uncore is required to read the vgpu capabilities while the vgpu capabilities are required to decide if we need to initialize forcewake support. To remove this circular dependency, we can perform the required MMIO access by mmapping just the vgtif shared page in mmio space and use raw accessors. v2: rename check_vgpu to detect_vgpu (Chris) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniele Ceraolo Spurio authored
We'd like to introduce a display uncore with no forcewake domains, so let's avoid wasting memory and be ready to allocate only what we need. Even without multiple uncore, we still don't need all the domains on all gens. v2: avoid hidden control flow, improve checks (Tvrtko), fix IVB special case, add failure injection point Signed-off-by:
-
