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

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. > diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c > new file mode 100644 > index ..d36a0572 > --- /dev/null > +++ b/tests/core_hotunplug.c >

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

== 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 Summary --- **FAILUR

[Intel-gfx] [PATCH 3/4] 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 4/4] 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:

[Intel-gfx] [PATCH 2/4] 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 1/4] 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

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

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) >> +{ >> + struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm); >> +

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/edid: abstract override/firmware EDID retrieval

== Series Details == Series: series starting with [1/2] drm/edid: abstract override/firmware EDID retrieval URL : https://patchwork.freedesktop.org/series/61764/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6216_full -> Patchwork_13203_full ==

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/5] drm/i915: Reset only affected engines when handling error capture (rev3)

== Series Details == Series: series starting with [CI,1/5] drm/i915: Reset only affected engines when handling error capture (rev3) URL : https://patchwork.freedesktop.org/series/61758/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6216_full -> Patchwork_13202_full ==

[Intel-gfx] ✓ Fi.CI.IGT: success for Add support for new DMC headers

== Series Details == Series: Add support for new DMC headers URL : https://patchwork.freedesktop.org/series/61761/ State : success == Summary == CI Bug Log - changes from CI_DRM_6216_full -> Patchwork_13201_full Summary --- **SUCCESS

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Convert some more bits to use engine mmio accessors

== Series Details == Series: series starting with [CI,1/2] drm/i915: Convert some more bits to use engine mmio accessors URL : https://patchwork.freedesktop.org/series/61759/ State : success == Summary == CI Bug Log - changes from CI_DRM_6216_full -> Patchwork_13200_full =

[Intel-gfx] [PATCH] dma-fence: Signal all callbacks from dma_fence_release()

This is an illegal scenario, to free the fence whilst there are pending callbacks. Currently, we emit a WARN and then cast aside the callbacks leaving them dangling. Alternatively, we could set an error on the fence and then signal fence so that any dependency chains from the fence can be tidied up

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: use ranges for voltage level lookup

== Series Details == Series: drm/i915/icl: use ranges for voltage level lookup URL : https://patchwork.freedesktop.org/series/61742/ State : success == Summary == CI Bug Log - changes from CI_DRM_6213_full -> Patchwork_13198_full Summary --

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915/guc: always use Command Transport Buffers

== Series Details == Series: series starting with [CI,1/2] drm/i915/guc: always use Command Transport Buffers URL : https://patchwork.freedesktop.org/series/61739/ State : success == Summary == CI Bug Log - changes from CI_DRM_6211_full -> Patchwork_13197_full