[Intel-gfx] [PATCH 25/28] drm/i915: Pull kref into i915_address_space

Make the kref common to both derived structs (i915_ggtt and i915_ppgtt) so that we can safely reference count an abstract ctx->vm address space. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- .../gpu/drm/i915/gem/i915_gem_client_blt.c| 4 +- drivers/gpu/drm/i915/gem/i915_gem_co

[Intel-gfx] [PATCH 24/28] drm/i915: Allow page pinning to be in the background

Assume that pages may be pinned in a background task and use a completion event to synchronise with callers that must access the pages immediately. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 + drivers/gpu/drm/i915/gem/i915_gem_o

[Intel-gfx] [PATCH 10/28] drm/i915/execlists: Preempt-to-busy

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 s

[Intel-gfx] [PATCH 02/28] drm/i915: Track ggtt fence reservations under its own mutex

We can reduce the locking for fence registers from the dev->struct_mutex to a local mutex. We could introduce a mutex for the sole purpose of tracking the fence acquisition, except there is a little bit of overlap with the fault tracking, so use the i915_ggtt.mutex as it covers both. Signed-off-by

[Intel-gfx] [PATCH 26/28] drm/i915: Rename i915_hw_ppgtt to i915_ppgtt

Keeping the _hw_ in there does not help to distinguish it from its brethren i915_ggtt, so drop it. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 12 +-- .../gpu/drm/i915/gem/selfte

[Intel-gfx] [PATCH 16/28] drm/i915: Provide an i915_active.acquire callback

If we introduce a callback for i915_active that is only called the first time we use the i915_active and is symmetrically paired with the i915_active.retire callback, we can replace the open-coded and non-atomic implementations -- which will be very fragile (i.e. broken) upon removing the struct_mu

[Intel-gfx] [PATCH 28/28] drm/i915: Use vm->mutex for serialising GTT insertion

Serialising insertion into each of the global GTT and ppGTT accounts for a large chunk of the current struct_mutex serialisation requireemnts. (Note that it is not just the drm_mm / gtt management itself being serialised, but the pin count and various flags.) Previously, the main blocker for replac

[Intel-gfx] [PATCH 22/28] drm/i915: Only track bound elements of the GTT

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 2 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 20 +++ drivers/gpu/drm/i915/i915_gem_gtt.h | 5 - drivers/gpu/drm/i915/i915_vma.c | 12 ++- drivers/gpu/drm/

[Intel-gfx] [PATCH 08/28] drm/i915: Replace engine->timeline with a plain list

To continue the onslaught of removing the assumption of a global execution ordering, another casualty is the engine->timeline. Without an actual timeline to track, it is overkill and we can replace it with a much less grand plain list. We still need a list of requests inflight, for the simple purpo

[Intel-gfx] [PATCH 27/28] drm/i915: Allow vma binding to occur asynchronously

If we let pages be allocated asynchronously, we also then want to push the binding process into an asynchronous task. Make it so, utilising the recent improvements to fence error tracking and struct_mutex reduction. Signed-off-by: Chris Wilson --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c|

[Intel-gfx] [PATCH 20/28] drm/i915: Extract intel_frontbuffer active tracking

Move the active tracking for the frontbuffer operations out of the i915_gem_object and into its own first class (refcounted) object. In the process of detangling, we switch from low level request tracking to the easier i915_active -- with the plan that this avoids any potential atomic callbacks as

[Intel-gfx] [PATCH 13/28] drm/i915: Use forced preemptions in preference over hangcheck

How well does this work in practice? It means that unless someone else is attempting to run we do not reset infinite loops. Maybe that is a good thing. Opens: * This sacrifices error capture. Maybe make that an opt-in with a watchdog. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ur

[Intel-gfx] [PATCH 14/28] drm/i915: Add a label for config DRM_I915_SPIN_REQUEST

If we don't give it a label, it does not appear as a configuration option. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/Kconfig.profile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig.profile b/drivers/gpu/drm/i915/Kcon

[Intel-gfx] [PATCH 11/28] drm/i915/execlists: Minimalistic timeslicing

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,

[Intel-gfx] [PATCH 18/28] drm/i915/overlay: Switch to using i915_active tracking

Remove the raw i915_active_request tracking in favour of the higher level i915_active tracking for the sole purpose of making the lockless transition easier in later patches. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_active.h | 19 drivers/gpu/drm/i915/intel_overlay.c | 1

[Intel-gfx] [PATCH 12/28] drm/i915/execlists: Force preemption

If the preempted context takes too long to relinquish control, e.g. it is stuck inside a shader with arbitration disabled, evict that context with an engine reset. This ensures that preemptions are reasonably responsive, providing a tighter QoS for the more important context at the cost of flagging

[Intel-gfx] [PATCH 09/28] drm/i915: Flush the execution-callbacks on retiring

In the unlikely case the request completes while we regard it as not even executing on the GPU (see the next patch!), we have to flush any pending execution callbacks at retirement and ensure that we do not add any more. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 93 ++

[Intel-gfx] [PATCH 07/28] drm/i915: Stop retiring along engine

We no longer track the execution order along the engine and so no longer need to enforce ordering of retire along the engine. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 128 +++- 1 file changed, 52 insertions(+), 76 deletions(-) diff --git a/dr

[Intel-gfx] [PATCH 21/28] drm/i915: Coordinate i915_active with its own mutex

Forgo the struct_mutex serialisation for i915_active, and interpose its own mutex handling for active/retire. This is a multi-layered sleight-of-hand. First, we had to ensure that no active/retire callbacks accidentally inverted the mutex ordering rules, nor assumed that they were themselves seria

[Intel-gfx] [PATCH 01/28] drm/i915: Move fence register tracking from i915->mm to ggtt

As the fence registers only apply to regions inside the GGTT is makes more sense that we track these as part of the i915_ggtt and not the general mm. In the next patch, we will then pull the register locking underneath the i915_ggtt.mutex. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem

[Intel-gfx] [PATCH 03/28] drm/i915: Combine unbound/bound list tracking for objects

With async binding, we don't want to manage a bound/unbound list as we may end up running before we even acquire the pages. All that is required is keeping track of shrinkable objects, so reduce it to the minimum list. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_domain.c

[Intel-gfx] [PATCH 19/28] drm/i915: Forgo last_fence active request tracking

We were using the last_fence to track the last request that used this vma that might be interpreted by a fence register and forced ourselves to wait for this request before modifying any fence register that overlapped our vma. Due to requirement that we need to track any XY_BLT command, linear or t

[Intel-gfx] [RFC] Removing struct_mutex from around requests

The paint is not yet dry on this, and I don't expect it to pass BAT. (Trybot has been down so unable to precheck for silly bugs.) There is one race in i915_active.retire that eludes me (enabling kasan and friends hides the race, making debugging harder than it should be!) and I am sure that there a

[Intel-gfx] [PATCH 17/28] drm/i915: Push the i915_active.retire into a worker

As we need to use a mutex to serialisation i915_active activation (because we want to allow the callback to sleep), we need to push the i915_active.retire into a worker callback in case we get need to retire from an atomic context. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_active

[Intel-gfx] [PATCH 05/28] drm/i915: Make the semaphore saturation mask global

The idea behind keeping the saturation mask local to a context backfired spectacularly. The premise with the local mask was that we would be more proactive in attempting to use semaphores after each time the context idled, and that all new contexts would attempt to use semaphores ignoring the curre

[Intel-gfx] [PATCH 06/28] drm/i915: Keep contexts pinned until after the next kernel context switch

We need to keep the context image pinned in memory until after the GPU has finished writing into it. Since it continues to write as we signal the final breadcrumb, we need to keep it pinned until the request after it is complete. Currently we know the order in which requests execute on each engine,

[Intel-gfx] [PATCH 23/28] drm/i915: Propagate fence errors

Errors spread like wildfire, and must eventually be returned to the user. They need to be captured and passed along the flow of fences, infecting each in turn with the existing error, until finally they fall out of a user visible result. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ---

[Intel-gfx] [PATCH 15/28] drm/i915: Throw away the active object retirement complexity

Remove the accumulated optimisations that we have for i915_vma_retire and reduce it to the bare essential of tracking the active object reference. This allows us to only use atomic operations, and so will be able to avoid the struct_mutex requirement. The principal loss here is the shrinker MRU bu

[Intel-gfx] [PATCH 04/28] drm/i915: Promote i915->mm.obj_lock to be irqsafe

The intent is to be update the mm.lists from inside a irqsoff section (e.g. from a softirq rcu workqueue), ergo we need to make the mm.obj_lock irqsafe. Fixes: 3b4fa9640ccd ("drm/i915: Track the purgeable objects on a separate eviction list") Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Cc:

Re: [Intel-gfx] [PATCH i-g-t v11 1/1] tests: Add a new test for device hot unplug

On Monday, June 10, 2019 8:49:38 AM CEST Petri Latvala wrote: > On Fri, Jun 07, 2019 at 01:51:42PM +0200, Janusz Krzysztofik wrote: > > - use SPDX license identifier, > > > Why? We don't use those in IGT. I must have had got an idea to change it from somewhere, unfortunately I'm not able to rec

Re: [Intel-gfx] [PATCH v6 3/8] drm/i915: vgpu ppgtt update pv optimization

Quoting Zhang, Xiaolin (2019-06-10 02:32:18) > On 06/04/2019 05:01 PM, Chris Wilson wrote: > > Quoting Xiaolin Zhang (2019-06-03 07:02:44) > >> +static void gen8_ppgtt_clear_4lvl_pv(struct i915_address_space *vm, > >> + u64 start, u64 length) > >> +{ > >> + str

Re: [Intel-gfx] [PATCH v6 3/8] drm/i915: vgpu ppgtt update pv optimization

On 06/10/2019 03:44 PM, Chris Wilson wrote: > Quoting Zhang, Xiaolin (2019-06-10 02:32:18) >> On 06/04/2019 05:01 PM, Chris Wilson wrote: >>> Quoting Xiaolin Zhang (2019-06-03 07:02:44) +static void gen8_ppgtt_clear_4lvl_pv(struct i915_address_space *vm, +

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Grammar s/the its/its/

On Mon, 10 Jun 2019, Patchwork wrote: > == Series Details == > > Series: drm/i915: Grammar s/the its/its/ > URL : https://patchwork.freedesktop.org/series/61768/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_6217_full -> Patchwork_13204_full > =

[Intel-gfx] [PATCH] drm/i915: Backlight control via VESA eDP aux interface

The latest VBT support backlight control via aux. We have to check VBT's setting before doing backlight initialization. Then Driver will assign correct callback function for eDP backlight control. Cc: Jani Nikula Cc: Jose Roberto de Souza Cc: Cooper Chiou Signed-off-by: Lee, Shawn C --- driv

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: move more atomic plane declarations to intel_atomic_plane.h

On Thu, 06 Jun 2019, Chris Wilson wrote: > Quoting Jani Nikula (2019-06-06 13:22:02) >> Some function declarations in intel_drv.h were missed when >> intel_atomic_plane.h was created. >> >> Signed-off-by: Jani Nikula >> --- >> drivers/gpu/drm/i915/intel_atomic_plane.h | 16 >>

[Intel-gfx] [PATCH] drm/i915/perf: fix ICL perf register offsets

We got the wrong offsets (could they have changed?). New values were computed off an error state by looking up the register offset in the context image as written by the HW. Signed-off-by: Lionel Landwerlin Fixes: 1de401c08fa805 ("drm/i915/perf: enable perf support on ICL") --- drivers/gpu/drm/i

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Move i915_check_and_clear_faults to intel_reset.c

== Series Details == Series: drm/i915: Move i915_check_and_clear_faults to intel_reset.c URL : https://patchwork.freedesktop.org/series/61771/ State : success == Summary == CI Bug Log - changes from CI_DRM_6220_full -> Patchwork_13205_full

[Intel-gfx] [PATCH v2] drm: add fallback override/firmware EDID modes workaround

We've moved the override and firmware EDID (simply "override EDID" from now on) handling to the low level drm_do_get_edid() function in order to transparently use the override throughout the stack. The idea is that you get the override EDID via the ->get_modes() hook. Unfortunately, there are scen

[Intel-gfx] [PATCH] drm/i915: Fix GVT balloon fail path handling

For any reason if GVT balloon failed, deballoon would be called. This adds a simple mask to check validity of balloon spaces. When failure happens, that mask is used to track for deballoon, so it won't cause any invalid space reference in fail path, which fixed kernel oops when balloon error happen

Re: [Intel-gfx] [PATCH 2/2] drm: add fallback override/firmware EDID modes workaround

On Sat, 08 Jun 2019, Paul Wise wrote: > On Sat, 2019-06-08 at 13:10 +0800, Paul Wise wrote: > >> I've tested these two patches on top of Linux v5.2-rc3 and the EDID >> override works correctly on an Intel Ironlake GPU with a monitor that >> lost its EDID a while ago. > > While testing I noticed a

Re: [Intel-gfx] [PATCH 04/28] drm/i915: Promote i915->mm.obj_lock to be irqsafe

On Mon, 10 Jun 2019 at 08:21, Chris Wilson wrote: > > The intent is to be update the mm.lists from inside a irqsoff section > (e.g. from a softirq rcu workqueue), ergo we need to make the mm.obj_lock > irqsafe. > > Fixes: 3b4fa9640ccd ("drm/i915: Track the purgeable objects on a separate > evicti

Re: [Intel-gfx] [PATCH] drm/i915: Backlight control via VESA eDP aux interface

On Mon, 10 Jun 2019, "Lee, Shawn C" wrote: > The latest VBT support backlight control via aux. We have to > check VBT's setting before doing backlight initialization. > Then Driver will assign correct callback function for eDP > backlight control. > > Cc: Jani Nikula > Cc: Jose Roberto de Souza

Re: [Intel-gfx] [PATCH 01/28] drm/i915: Move fence register tracking from i915->mm to ggtt

Chris Wilson writes: > As the fence registers only apply to regions inside the GGTT is makes > more sense that we track these as part of the i915_ggtt and not the > general mm. In the next patch, we will then pull the register locking > underneath the i915_ggtt.mutex. > > Signed-off-by: Chris Wil

Re: [Intel-gfx] [PATCH] drm/i915: Backlight control via VESA eDP aux interface

On Mon, 10 Jun 2019, Jani Nikula wrote: > On Mon, 10 Jun 2019, "Lee, Shawn C" wrote: >> The latest VBT support backlight control via aux. We have to >> check VBT's setting before doing backlight initialization. >> Then Driver will assign correct callback function for eDP >> backlight control. >>

[Intel-gfx] ✓ Fi.CI.IGT: success for Legacy mmio accessor macro pruning

== Series Details == Series: Legacy mmio accessor macro pruning URL : https://patchwork.freedesktop.org/series/61772/ State : success == Summary == CI Bug Log - changes from CI_DRM_6220_full -> Patchwork_13206_full Summary --- **SUCC

[Intel-gfx] [CI] drm/i915: Promote i915->mm.obj_lock to be irqsafe

The intent is to be able to update the mm.lists from inside an irqsoff section (e.g. from a softirq rcu workqueue), ergo we need to make the i915->mm.obj_lock irqsafe. Fixes: 3b4fa9640ccd ("drm/i915: Track the purgeable objects on a separate eviction list") Bugzilla: https://bugs.freedesktop.org/

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/fb-helper: Move modesetting code to drm_client (rev9)

== Series Details == Series: drm/fb-helper: Move modesetting code to drm_client (rev9) URL : https://patchwork.freedesktop.org/series/58597/ State : warning == Summary == $ dim checkpatch origin/drm-tip 12c568eec3fc drm/fb-helper: Remove drm_fb_helper_connector -:596: WARNING:LONG_LINE: line o

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/fb-helper: Move modesetting code to drm_client (rev9)

== Series Details == Series: drm/fb-helper: Move modesetting code to drm_client (rev9) URL : https://patchwork.freedesktop.org/series/58597/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/fb-helper: Remove drm_fb_helper_connector -O:drivers/gpu/drm

[Intel-gfx] [PATCH] drm/i915: Allow interrupts when taking the timeline->mutex

Before we commit ourselves to writing commands into the ringbuffer and submitting the request, allow signals to interrupt acquisition of the timeline mutex. We allow ourselves to be interrupted at any time later if we need to block for space in the ring, anyway. Signed-off-by: Chris Wilson --- d

[Intel-gfx] ✗ Fi.CI.BAT: failure for dma-fence: Signal all callbacks from dma_fence_release()

== Series Details == Series: dma-fence: Signal all callbacks from dma_fence_release() URL : https://patchwork.freedesktop.org/series/61811/ State : failure == Summary == Applying: dma-fence: Signal all callbacks from dma_fence_release() Using index info to reconstruct a base tree... M dr

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/fb-helper: Move modesetting code to drm_client (rev9)

== Series Details == Series: drm/fb-helper: Move modesetting code to drm_client (rev9) URL : https://patchwork.freedesktop.org/series/58597/ State : success == Summary == CI Bug Log - changes from CI_DRM_6225 -> Patchwork_13211 Summary

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: Move fence register tracking from i915->mm to ggtt

== Series Details == Series: series starting with [1/4] drm/i915: Move fence register tracking from i915->mm to ggtt URL : https://patchwork.freedesktop.org/series/61821/ State : warning == Summary == $ dim checkpatch origin/drm-tip dc97c7ab3550 drm/i915: Move fence register tracking from i91

[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_engines: Skip trying to read a non-existent TIMESTAMP

The per-engine TIMESTAMP (at least at the offset I know about) only came into being with gen6. So skip the test on older gen as the results are garbage. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110874 Signed-off-by: Chris Wilson --- tests/i915/gem_ctx_engines.c | 2 ++ 1 file chang

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915: Move fence register tracking from i915->mm to ggtt

== Series Details == Series: series starting with [1/4] drm/i915: Move fence register tracking from i915->mm to ggtt URL : https://patchwork.freedesktop.org/series/61821/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Move fence register tra

Re: [Intel-gfx] [v7][PATCH 03/12] drm/i915: Add func to compare hw/sw gamma lut

On 31-May-19 8:58 PM, Ville Syrjälä wrote: On Wed, May 29, 2019 at 03:20:53PM +0530, Swati Sharma wrote: v3: -Rebase v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani] -Added the default label above the correct label [Jani] -Corrected smatch warn "variable derefe

Re: [Intel-gfx] [PATCH 01/28] drm/i915: Move fence register tracking from i915->mm to ggtt

Quoting Mika Kuoppala (2019-06-10 10:46:43) > Chris Wilson writes: > > static int i915_gem_fence_regs_info(struct seq_file *m, void *data) > > { > > - struct drm_i915_private *dev_priv = node_to_i915(m->private); > > - struct drm_device *dev = &dev_priv->drm; > > - int i, ret; > > +

Re: [Intel-gfx] [PATCH 03/28] drm/i915: Combine unbound/bound list tracking for objects

On Mon, 10 Jun 2019 at 08:21, Chris Wilson wrote: > > With async binding, we don't want to manage a bound/unbound list as we > may end up running before we even acquire the pages. All that is > required is keeping track of shrinkable objects, so reduce it to the > minimum list. > > Signed-off-by:

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: Move fence register tracking from i915->mm to ggtt

== Series Details == Series: series starting with [1/4] drm/i915: Move fence register tracking from i915->mm to ggtt URL : https://patchwork.freedesktop.org/series/61821/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6225 -> Patchwork_13213 ===

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_engines: Skip trying to read a non-existent TIMESTAMP

On 10/06/2019 11:46, Chris Wilson wrote: The per-engine TIMESTAMP (at least at the offset I know about) only came into being with gen6. So skip the test on older gen as the results are garbage. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110874 Signed-off-by: Chris Wilson --- test

Re: [Intel-gfx] [PATCH 03/28] drm/i915: Combine unbound/bound list tracking for objects

Quoting Matthew Auld (2019-06-10 12:01:17) > On Mon, 10 Jun 2019 at 08:21, Chris Wilson wrote: > > @@ -329,7 +329,8 @@ void i915_gem_free_object(struct drm_gem_object > > *gem_obj) > > > > obj->mm.madv = I915_MADV_DONTNEED; > > > > - if (i915_gem_object_has_pages(obj

Re: [Intel-gfx] [PATCH] drm/i915: Allow interrupts when taking the timeline->mutex

On 10/06/2019 11:36, Chris Wilson wrote: Before we commit ourselves to writing commands into the ringbuffer and submitting the request, allow signals to interrupt acquisition of the timeline mutex. We allow ourselves to be interrupted at any time later if we need to block for space in the ring,

[Intel-gfx] [CI] drm/i915: Promote i915->mm.obj_lock to be irqsafe

The intent is to be able to update the mm.lists from inside an irqsoff section (e.g. from a softirq rcu workqueue), ergo we need to make the i915->mm.obj_lock irqsafe. v2: can_discard_pages() ensures we are shrinkable Fixes: 3b4fa9640ccd ("drm/i915: Track the purgeable objects on a separate evic

Re: [Intel-gfx] [PATCH] drm/i915: Allow interrupts when taking the timeline->mutex

Quoting Tvrtko Ursulin (2019-06-10 12:08:40) > > On 10/06/2019 11:36, Chris Wilson wrote: > > Before we commit ourselves to writing commands into the > > ringbuffer and submitting the request, allow signals to interrupt > > acquisition of the timeline mutex. We allow ourselves to be interrupted >

Re: [Intel-gfx] [PATCH] drm/i915: Fix GVT balloon fail path handling

Quoting Zhenyu Wang (2019-06-10 10:28:19) > For any reason if GVT balloon failed, deballoon would be called. > This adds a simple mask to check validity of balloon spaces. When > failure happens, that mask is used to track for deballoon, so it > won't cause any invalid space reference in fail path,

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/28] drm/i915: Move fence register tracking from i915->mm to ggtt

== Series Details == Series: series starting with [01/28] drm/i915: Move fence register tracking from i915->mm to ggtt URL : https://patchwork.freedesktop.org/series/61824/ State : failure == Summary == Applying: drm/i915: Move fence register tracking from i915->mm to ggtt Applying: drm/i915:

Re: [Intel-gfx] [PATCH 01/28] drm/i915: Move fence register tracking from i915->mm to ggtt

Chris Wilson writes: > Quoting Mika Kuoppala (2019-06-10 10:46:43) >> Chris Wilson writes: >> > static int i915_gem_fence_regs_info(struct seq_file *m, void *data) >> > { >> > - struct drm_i915_private *dev_priv = node_to_i915(m->private); >> > - struct drm_device *dev = &dev_priv->drm

[Intel-gfx] [CI 2/6] drm/i915: Convert i915_reg_read_ioctl to use explicit mmio accessors

From: Tvrtko Ursulin No excuse for code located in intel_uncore.c to not use intel_uncore_ helpers. Signed-off-by: Tvrtko Ursulin Suggested-by: Jani Nikula Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/intel_uncore.c | 23 ++- 1 file changed, 14 insertions(+), 9 delet

[Intel-gfx] [CI 6/6] drm/i915: Remove I915_READ64 and I915_READ64_32x2

From: Tvrtko Ursulin Now that all their users are gone we can remove the macros and accompanying duplicated comment. Signed-off-by: Tvrtko Ursulin Suggested-by: Jani Nikula Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 18 -- 1 file changed, 18 deletions(-)

[Intel-gfx] [CI 3/6] drm/i915: Convert icl_get_stolen_reserved to uncore mmio accessors

From: Tvrtko Ursulin More removal of implicit dev_priv. Signed-off-by: Tvrtko Ursulin Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c b/drivers/gpu/drm/i

[Intel-gfx] [CI 1/6] drm/i915: Eliminate unused mmio accessors

From: Tvrtko Ursulin On the path of removing mmio accessors with implicit dev_priv, easy first step is to remove all such unused macros. Signed-off-by: Tvrtko Ursulin Suggested-by: Jani Nikula Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 4 1 file changed, 4 deletions(

[Intel-gfx] [CI 4/6] drm/i915: Convert gem_record_fences to uncore mmio accessors

From: Tvrtko Ursulin More implicit dev_priv removal. Signed-off-by: Tvrtko Ursulin Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/i915_gpu_error.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/

[Intel-gfx] [CI 5/6] drm/i915: Convert intel_read_wm_latency to uncore mmio accessors

From: Tvrtko Ursulin More implicit dev_priv removal. Signed-off-by: Tvrtko Ursulin Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/intel_pm.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 8

Re: [Intel-gfx] [PATCH 14/28] drm/i915: Add a label for config DRM_I915_SPIN_REQUEST

Chris Wilson writes: > If we don't give it a label, it does not appear as a configuration > option. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/Kconfig.profile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Backlight control via VESA eDP aux interface

== Series Details == Series: drm/i915: Backlight control via VESA eDP aux interface URL : https://patchwork.freedesktop.org/series/61825/ State : success == Summary == CI Bug Log - changes from CI_DRM_6225 -> Patchwork_13215 Summary ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/edid: abstract override/firmware EDID retrieval (rev2)

== Series Details == Series: series starting with [1/2] drm/edid: abstract override/firmware EDID retrieval (rev2) URL : https://patchwork.freedesktop.org/series/61764/ State : warning == Summary == $ dim checkpatch origin/drm-tip d5896a186b31 drm/edid: abstract override/firmware EDID retriev

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix TypeC port mode switching (rev2)

== Series Details == Series: drm/i915: Fix TypeC port mode switching (rev2) URL : https://patchwork.freedesktop.org/series/61590/ State : success == Summary == CI Bug Log - changes from CI_DRM_6221_full -> Patchwork_13209_full Summary -

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: fix ICL perf register offsets

== Series Details == Series: drm/i915/perf: fix ICL perf register offsets URL : https://patchwork.freedesktop.org/series/61826/ State : success == Summary == CI Bug Log - changes from CI_DRM_6225 -> Patchwork_13216 Summary --- **SUCC

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/edid: abstract override/firmware EDID retrieval (rev2)

== Series Details == Series: series starting with [1/2] drm/edid: abstract override/firmware EDID retrieval (rev2) URL : https://patchwork.freedesktop.org/series/61764/ State : success == Summary == CI Bug Log - changes from CI_DRM_6225 -> Patchwork_13217 =

[Intel-gfx] [PATCH i-g-t] i915/gem_mmap_gtt: Disregard forked subtests on ICL for reasons

Nothing to see here, please move along. XXX: Update with better bugzilla Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107713#c125 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Martin Peres --- tests/i915/gem_mmap_gtt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests

[Intel-gfx] [PATCH v2] drm/i915: Make read_subslice_reg take engine

From: Tvrtko Ursulin The function operates on the render engine so make the input reflect it. v2: * Pass engine to read_subslice_reg. (Chris) * Drop inline from read_subslice_reg. Signed-off-by: Tvrtko Ursulin Suggested-by: Rodrigo Vivi Cc: Chris Wilson Reviewed-by: Chris Wilson --- driv

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_mmap_gtt: Disregard forked subtests on ICL for reasons

On 10/06/2019 15:55, Chris Wilson wrote: > Nothing to see here, please move along. > > XXX: Update with better bugzilla https://bugs.freedesktop.org/show_bug.cgi?id=110882 > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107713#c125 > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala

[Intel-gfx] [RFC] drm/i915/hangcheck: Look at instdone for all engines

From: Tvrtko Ursulin It seems intel_engine_get_instdone is able to get instdone for all engines but intel_hangcheck.c/subunits_stuck decides to ignore it for non render. We can just drop the check in subunits_stuck since the checks on unavailable fields will always return stuck, which when bitwi

[Intel-gfx] [PATCH i-g-t v2] i915/gem_mmap_gtt: Disregard forked subtests on ICL for reasons

Nothing to see here, please move along. References: https://bugs.freedesktop.org/show_bug.cgi?id=110882 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Martin Peres --- tests/i915/gem_mmap_gtt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem

Re: [Intel-gfx] [RFC] drm/i915/hangcheck: Look at instdone for all engines

Quoting Tvrtko Ursulin (2019-06-10 14:01:10) > From: Tvrtko Ursulin > > It seems intel_engine_get_instdone is able to get instdone for all engines > but intel_hangcheck.c/subunits_stuck decides to ignore it for non render. > > We can just drop the check in subunits_stuck since the checks on > un

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix GVT balloon fail path handling

== Series Details == Series: drm/i915: Fix GVT balloon fail path handling URL : https://patchwork.freedesktop.org/series/61830/ State : success == Summary == CI Bug Log - changes from CI_DRM_6225 -> Patchwork_13218 Summary --- **SUCC

Re: [Intel-gfx] [RFC] drm/i915/hangcheck: Look at instdone for all engines

On 10/06/2019 14:05, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-06-10 14:01:10) From: Tvrtko Ursulin It seems intel_engine_get_instdone is able to get instdone for all engines but intel_hangcheck.c/subunits_stuck decides to ignore it for non render. We can just drop the check in subuni

Re: [Intel-gfx] [RFC] drm/i915/hangcheck: Look at instdone for all engines

Quoting Tvrtko Ursulin (2019-06-10 14:16:32) > > On 10/06/2019 14:05, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-06-10 14:01:10) > >> From: Tvrtko Ursulin > >> > >> It seems intel_engine_get_instdone is able to get instdone for all engines > >> but intel_hangcheck.c/subunits_stuck decid

[Intel-gfx] [PATCH v2 2/5] drm/i915: Rename HSW/BDW PLL bits

From: Ville Syrjälä Give the PLL control register bits better names on HSW/BDW. v2: Fix the copy paste fails in SPLL_REF defines (Maarten) Cc: Maarten Lankhorst Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 32 +-- drivers/gpu/drm/i915/intel

[Intel-gfx] [PATCH] Revert "drm/i915/icl: More workaround for port F detection due to broken VBTs"

This reverts commit 1aa3750885fbcece5a0c9e6bbcd014ac526cea41. References: https://bugs.freedesktop.org/show_bug.cgi?id=110882 --- include/drm/i915_pciids.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index 6d60ea68c

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow interrupts when taking the timeline->mutex

== Series Details == Series: drm/i915: Allow interrupts when taking the timeline->mutex URL : https://patchwork.freedesktop.org/series/61833/ State : success == Summary == CI Bug Log - changes from CI_DRM_6225 -> Patchwork_13219 Summary ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Promote i915->mm.obj_lock to be irqsafe (rev2)

== Series Details == Series: drm/i915: Promote i915->mm.obj_lock to be irqsafe (rev2) URL : https://patchwork.freedesktop.org/series/61832/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6225 -> Patchwork_13220 Summary -

Re: [Intel-gfx] [PATCH] Revert "drm/i915/icl: More workaround for port F detection due to broken VBTs"

On Mon, Jun 10, 2019 at 02:34:13PM +0100, Chris Wilson wrote: > This reverts commit 1aa3750885fbcece5a0c9e6bbcd014ac526cea41. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=110882 How is it related? None of the above bug reports are about a 0x8A5D box. 0x8A56 is one and 0x8A5A is th

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/ehl: Add support for DPLL4 (v5) (rev2)

== Series Details == Series: drm/i915/ehl: Add support for DPLL4 (v5) (rev2) URL : https://patchwork.freedesktop.org/series/61684/ State : success == Summary == CI Bug Log - changes from CI_DRM_6222_full -> Patchwork_13210_full Summary

[Intel-gfx] [CI] drm/i915: Promote i915->mm.obj_lock to be irqsafe

The intent is to be able to update the mm.lists from inside an irqsoff section (e.g. from a softirq rcu workqueue), ergo we need to make the i915->mm.obj_lock irqsafe. v2: can_discard_pages() ensures we are shrinkable v3: Beware shadowing of 'flags' Fixes: 3b4fa9640ccd ("drm/i915: Track the purge

Re: [Intel-gfx] [PATCH] Revert "drm/i915/icl: More workaround for port F detection due to broken VBTs"

Quoting Imre Deak (2019-06-10 15:40:13) > On Mon, Jun 10, 2019 at 02:34:13PM +0100, Chris Wilson wrote: > > This reverts commit 1aa3750885fbcece5a0c9e6bbcd014ac526cea41. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=110882 > > How is it related? None of the above bug reports ar

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/6] drm/i915: Eliminate unused mmio accessors

== Series Details == Series: series starting with [CI,1/6] drm/i915: Eliminate unused mmio accessors URL : https://patchwork.freedesktop.org/series/61837/ State : success == Summary == CI Bug Log - changes from CI_DRM_6225 -> Patchwork_13221

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Make read_subslice_reg take engine

== Series Details == Series: drm/i915: Make read_subslice_reg take engine URL : https://patchwork.freedesktop.org/series/61841/ State : success == Summary == CI Bug Log - changes from CI_DRM_6225 -> Patchwork_13222 Summary --- **SUCC

Re: [Intel-gfx] [PATCH] drm/i915/perf: fix ICL perf register offsets

On Monday, June 10, 2019 1:19:14 AM PDT Lionel Landwerlin wrote: > We got the wrong offsets (could they have changed?). New values were > computed off an error state by looking up the register offset in the > context image as written by the HW. > > Signed-off-by: Lionel Landwerlin > Fixes: 1de401

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hangcheck: Look at instdone for all engines

== Series Details == Series: drm/i915/hangcheck: Look at instdone for all engines URL : https://patchwork.freedesktop.org/series/61843/ State : success == Summary == CI Bug Log - changes from CI_DRM_6225 -> Patchwork_13223 Summary ---

[Intel-gfx] [RFC v2 00/14] Implicit dev_priv removal

From: Tvrtko Ursulin Mostly patches reworking the code and GEM init paths to remove some implicit dev_priv dependencies (I915_READ/I915_WRITE), plus some small tweaks to tidy GEM init paths to use more logical input parameters (enabled by the conversion to uncore mmio accessors). v2: * Introduc

  1   2   >