[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Fix use-after-free in intel_vgpu_create_workload

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915/gvt: Fix use-after-free in intel_vgpu_create_workload URL : https://patchwork.freedesktop.org/series/64804/ State : success == Summary == CI Bug Log - changes from CI_DRM_6642 -> Patchwork_13892

[Intel-gfx] ✗ Fi.CI.BAT: failure for linux-next: build failure after merge of the drm-misc tree

2019-08-06 Thread Patchwork
== Series Details == Series: linux-next: build failure after merge of the drm-misc tree URL : https://patchwork.freedesktop.org/series/64809/ State : failure == Summary == Applying: linux-next: build failure after merge of the drm-misc tree error: sha1 information is lacking or useless

[Intel-gfx] linux-next: build failure after merge of the drm-misc tree

2019-08-06 Thread Stephen Rothwell
Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function 'amdgpu_bo_release_notify': drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1245:28: error: 'struct ttm_buffer_object' has no member

[Intel-gfx] linux-next: manual merge of the drm-misc tree with the amdgpu tree

2019-08-06 Thread Stephen Rothwell
Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/ttm/ttm_bo.c between commit: 274840e54422 ("drm/ttm: Add release_notify callback to ttm_bo_driver") from the amdgpu tree and commit: b96f3e7c8069 ("drm/ttm: use gem vma_node") from the drm-misc

[Intel-gfx] [PATCH] drm/i915/gvt: Fix use-after-free in intel_vgpu_create_workload

2019-08-06 Thread Gustavo A. R. Silva
kmem_cache_free() frees *workload*, hence there is a use-after-free bug when calling function gvt_vgpu_err(). Fix this by storing the value of workload->wa_ctx.indirect_ctx.guest_gma and workload->wa_ctx.per_ctx.guest_gma into automatic variable guest_gma before freeing *workload*, for its

[Intel-gfx] ✓ Fi.CI.IGT: success for Send a hotplug when edid changes (rev4)

2019-08-06 Thread Patchwork
== Series Details == Series: Send a hotplug when edid changes (rev4) URL : https://patchwork.freedesktop.org/series/62816/ State : success == Summary == CI Bug Log - changes from CI_DRM_6639_full -> Patchwork_13889_full Summary ---

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Patchwork
== Series Details == Series: series starting with [CI,1/2] drm/i915/gem: Make caps.scheduler static URL : https://patchwork.freedesktop.org/series/64771/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6639_full -> Patchwork_13888_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: Refactor oa object to better manage resources (rev5)

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915/perf: Refactor oa object to better manage resources (rev5) URL : https://patchwork.freedesktop.org/series/60176/ State : success == Summary == CI Bug Log - changes from CI_DRM_6642 -> Patchwork_13891

Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/display: Rename update_crtcs() to commit_modeset_enables()

2019-08-06 Thread Tolakanahalli Pradeep, Madhumitha
On Mon, 2019-06-24 at 14:08 -0700, Manasi Navare wrote: > This patch has no functional changes. This just renames the > update_crtcs() > hooks to commit_modeset_enables() to match the drm_atomic helper > naming > conventions. > > Suggested-by: Daniel Vetter > Cc: Ville Syrjälä > Cc: Maarten

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix panic if nothing to promote after preempt on reset

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: Fix panic if nothing to promote after preempt on reset URL : https://patchwork.freedesktop.org/series/64769/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6639_full -> Patchwork_13887_full

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/perf: Refactor oa object to better manage resources (rev5)

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915/perf: Refactor oa object to better manage resources (rev5) URL : https://patchwork.freedesktop.org/series/60176/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/perf: Refactor oa object to better manage

Re: [Intel-gfx] [PATCH v3 hmm 10/11] drm/amdkfd: use mmu_notifier_put

2019-08-06 Thread Kuehling, Felix
On 2019-08-06 19:15, Jason Gunthorpe wrote: > From: Jason Gunthorpe > > The sequence of mmu_notifier_unregister_no_release(), > mmu_notifier_call_srcu() is identical to mmu_notifier_put() with the > free_notifier callback. > > As this is the last user of those APIs, converting it means we can

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: Refactor oa object to better manage resources (rev5)

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915/perf: Refactor oa object to better manage resources (rev5) URL : https://patchwork.freedesktop.org/series/60176/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0e3aea71c1bb drm/i915/perf: Refactor oa object to better manage resources -:523:

Re: [Intel-gfx] [PATCH v7 2/4] drm/i915: Add _TRANS2()

2019-08-06 Thread Lucas De Marchi
On Tue, Jul 30, 2019 at 03:47:51PM -0700, Jose Souza wrote: A new macro that is going to be added in a further patch will need to adjust the offset returned by _MMIO_TRANS2(), so here adding _TRANS2() and moving most of the implementation of _MMIO_TRANS2() to it and while at it taking the

[Intel-gfx] [PATCH] drm/i915/perf: Refactor oa object to better manage resources

2019-08-06 Thread Umesh Nerlige Ramappa
The oa object manages the oa buffer and must be allocated when the user intends to read performance counter snapshots. This can be achieved by making the oa object part of the stream object which is allocated when a stream is opened by the user. Attributes in the oa object that are gen-specific

Re: [Intel-gfx] [PATCH v7 1/4] drm/i915/bdw+: Move misc display IRQ handling to it own function

2019-08-06 Thread Lucas De Marchi
On Tue, Jul 30, 2019 at 03:47:50PM -0700, Jose Souza wrote: Just moving it to reduce the tabs and avoid break code lines. No behavior changes intended here. v2: - Reading misc display IRQ outside of gen8_de_misc_irq_handler() as other irq handlers (Dhinakaran) Cc: Dhinakaran Pandiyan

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: abstract display suspend/resume operations

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: abstract display suspend/resume operations URL : https://patchwork.freedesktop.org/series/64768/ State : success == Summary == CI Bug Log - changes from CI_DRM_6639_full -> Patchwork_13886_full

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_eio: Break early for small rings

2019-08-06 Thread Matthew Auld
On Mon, 29 Jul 2019 at 13:27, Chris Wilson wrote: > > If the shared legacy ringbuffer is too small to fit 64 new contexts, it > will hang and report -EIO before we are expecting it. Accommodate this > eio as it part of the ABI we are testing. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/22] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Chris Wilson
Quoting Chris Wilson (2019-08-06 21:20:31) > Quoting Patchwork (2019-08-06 21:14:15) > > Possible regressions > > > > * igt@gem_eio@in-flight-contexts-10ms: > > - shard-snb: [PASS][1] -> [FAIL][2] +2 similar issues > >[1]: > >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: some more header juggling (rev3)

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: some more header juggling (rev3) URL : https://patchwork.freedesktop.org/series/64764/ State : success == Summary == CI Bug Log - changes from CI_DRM_6639_full -> Patchwork_13885_full Summary ---

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/22] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Chris Wilson
Quoting Patchwork (2019-08-06 21:14:15) > Possible regressions > > * igt@gem_eio@in-flight-contexts-10ms: > - shard-snb: [PASS][1] -> [FAIL][2] +2 similar issues >[1]: >

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/22] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Patchwork
== Series Details == Series: series starting with [01/22] drm/i915/gem: Make caps.scheduler static URL : https://patchwork.freedesktop.org/series/64761/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6639_full -> Patchwork_13884_full

Re: [Intel-gfx] [PATCH 8/8] dma-buf: nuke reservation_object seq number

2019-08-06 Thread Chris Wilson
Quoting Christian König (2019-08-06 16:01:34) > The only remaining use for this is to protect against setting a new exclusive > fence while we grab both exclusive and shared. That can also be archived by > looking if the exclusive fence has changed or not after completing the > operation. > >

Re: [Intel-gfx] [PATCH 5/8] dma-buf: further relax reservation_object_add_shared_fence

2019-08-06 Thread Chris Wilson
Quoting Christian König (2019-08-06 16:01:31) > Other cores don't busy wait any more and we removed the last user of checking > the seqno for changes. Drop updating the number for shared fences altogether. > > Signed-off-by: Christian König > --- > drivers/dma-buf/reservation.c

Re: [Intel-gfx] [PATCH 7/8] dma-buf: add reservation_object_fences helper

2019-08-06 Thread Chris Wilson
Quoting Christian König (2019-08-06 16:01:33) > Add a new helper to get a consistent set of pointers from the reservation > object. While at it group all access helpers together in the header file. Ah, needs to be earlier :) > +/** > + * reservation_object_fences - read consistent fence

Re: [Intel-gfx] [PATCH 6/8] dma-buf: simplify reservation_object_get_fences_rcu a bit

2019-08-06 Thread Chris Wilson
Quoting Christian König (2019-08-06 16:01:32) > We can add the exclusive fence to the list after making sure we got > a consistent state. > > Signed-off-by: Christian König Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 4/8] drm/i915: use new reservation_object_fences helper

2019-08-06 Thread Chris Wilson
Quoting Christian König (2019-08-06 16:01:30) > Instead of open coding the sequence loop use the new helper. I've missed something. What reservation_object_fences()? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 3/8] drm/i915: stop using seqcount for fenc pruning

2019-08-06 Thread Chris Wilson
Quoting Christian König (2019-08-06 16:01:29) > After waiting for a reservation object use > reservation_object_test_signaled_rcu > to opportunistically prune the fences on the object. > > This allows removal of the seqcount handling in the reservation object. > > Signed-off-by: Christian König

Re: [Intel-gfx] [PATCH 2/8] dma-buf: fix shared fence list handling in reservation_object_copy_fences

2019-08-06 Thread Chris Wilson
Quoting Christian König (2019-08-06 16:01:28) > Add some helpers to correctly allocate/free reservation_object_lists. > > Otherwise we might forget to drop dma_fence references on list destruction. > > Signed-off-by: Christian König > --- > drivers/dma-buf/reservation.c | 65

Re: [Intel-gfx] [PATCH 1/8] dma-buf: fix busy wait for new shared fences

2019-08-06 Thread Chris Wilson
Quoting Christian König (2019-08-06 16:01:27) > When reservation_object_add_shared_fence is replacing an old fence with a new > one we should not drop the old one before the new one is in place. > > Otherwise other cores can busy wait for the new one to appear. I see. The reader will see a

Re: [Intel-gfx] [PATCH v3 0/3] Send a hotplug when edid changes

2019-08-06 Thread Daniel Vetter
On Tue, Aug 6, 2019 at 4:06 PM Lisovskiy, Stanislav wrote: > > On Tue, 2019-08-06 at 15:51 +0200, Daniel Vetter wrote: > > On Tue, Aug 06, 2019 at 03:55:48PM +0300, Stanislav Lisovskiy wrote: > > > This series introduce to drm a way to determine if something else > > > except connection_status

Re: [Intel-gfx] [PATCH v2 01/34] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()

2019-08-06 Thread Ira Weiny
On Sun, Aug 04, 2019 at 03:48:42PM -0700, john.hubb...@gmail.com wrote: > From: John Hubbard > > Provide a more capable variation of put_user_pages_dirty_lock(), > and delete put_user_pages_dirty(). This is based on the > following: > > 1. Lots of call sites become simpler if a bool is passed >

Re: [Intel-gfx] [PATCH v12 0/6] HDCP2.2 Phase II

2019-08-06 Thread Ramalingam C
On 2019-08-01 at 17:11:13 +0530, Ramalingam C wrote: > Series adds the content_type support for HDCP2.2. Along with that uevent > is sent for each HDCP state change triggered within kernel. > > Pekka have completed the Weston DRM-backend review in >

Re: [Intel-gfx] [PATCH] drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY

2019-08-06 Thread Rodrigo Vivi
On Tue, Aug 06, 2019 at 03:02:31PM +0300, Jani Nikula wrote: > On Thu, 18 Jul 2019, Rodrigo Vivi wrote: > > On Thu, Jul 18, 2019 at 10:25:51PM +0100, Chris Wilson wrote: > >> Quoting Rodrigo Vivi (2019-07-18 22:14:45) > >> > On Thu, Jul 18, 2019 at 09:58:16PM +0100, Chris Wilson wrote: > >> > >

Re: [Intel-gfx] drm/i915: always split up refactoring from functional changes!

2019-08-06 Thread Rodrigo Vivi
On Tue, Aug 06, 2019 at 03:22:07PM +0300, Jani Nikula wrote: > > Rodrigo's original patch was at v5 [1], and still stuck in discussion > around the *functional* change, while 99% of the patch is > *non-functional* refactoring that does not seem to be contentious. > > Let's do the sane thing and

Re: [Intel-gfx] [PULL] drm-misc-next

2019-08-06 Thread Maxime Ripard
On Tue, Aug 06, 2019 at 10:33:53AM +1000, Dave Airlie wrote: > On Sat, 3 Aug 2019 at 20:47, Maxime Ripard wrote: > > > > Hi Daniel, Dave, > > > > Here is the first (and pretty late) drm-misc-next PR. > > > > It's pretty big due to the lateness, but there's nothing really major > > showing up.

Re: [Intel-gfx] [PATCH 03/22] drm/i915: Defer final intel_wakeref_put to process context

2019-08-06 Thread Chris Wilson
Quoting Chris Wilson (2019-08-06 10:05:16) > As we need to acquire a mutex to serialise the final > intel_wakeref_put, we need to ensure that we are in process context at > that time. However, we want to allow operation on the intel_wakeref from > inside timer and other hardirq context, which

Re: [Intel-gfx] [PULL] drm-misc-next

2019-08-06 Thread Daniel Vetter
On Tue, Aug 06, 2019 at 06:01:46PM +0200, Maxime Ripard wrote: > On Tue, Aug 06, 2019 at 10:33:53AM +1000, Dave Airlie wrote: > > On Sat, 3 Aug 2019 at 20:47, Maxime Ripard > > wrote: > > > > > > Hi Daniel, Dave, > > > > > > Here is the first (and pretty late) drm-misc-next PR. > > > > > > It's

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use drm_i915_private directly from drv_get_drvdata() (rev3)

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: Use drm_i915_private directly from drv_get_drvdata() (rev3) URL : https://patchwork.freedesktop.org/series/64377/ State : success == Summary == CI Bug Log - changes from CI_DRM_6637_full -> Patchwork_13881_full

[Intel-gfx] [PATCH i-g-t] Add i915/gem_ctx_persistence

2019-08-06 Thread Chris Wilson
Sanity test existing persistence and new exciting non-persistent context behaviour. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Cc: Michał Winiarski Cc: Jon Bloomfield --- A couple of minor quick fixes, ickle@kabylake:~$ sudo ./intel-gpu-tools/build/tests/gem_ctx_persistence

Re: [Intel-gfx] [PULL] drm-misc-next

2019-08-06 Thread Daniel Vetter
On Tue, Aug 6, 2019 at 4:25 PM Rob Herring wrote: > > On Tue, Aug 6, 2019 at 1:34 AM Daniel Vetter wrote: > > > > On Tue, Aug 6, 2019 at 2:34 AM Dave Airlie wrote: > > > > > > On Sat, 3 Aug 2019 at 20:47, Maxime Ripard > > > wrote: > > > > > > > > Hi Daniel, Dave, > > > > > > > > Here is the

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Only enqueue already completed requests

2019-08-06 Thread Patchwork
== Series Details == Series: series starting with [1/5] drm/i915: Only enqueue already completed requests URL : https://patchwork.freedesktop.org/series/64781/ State : failure == Summary == Applying: drm/i915: Only enqueue already completed requests Applying: drm/i915/execlists: Force

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Mark up "sentinel" requests

2019-08-06 Thread Chris Wilson
Quoting Mika Kuoppala (2019-08-06 15:29:58) > Chris Wilson writes: > > > Sometimes we want to emit a terminator request, a request that flushes > > the pipeline and allows no request to come after it. This can be used > > for a "preempt-to-idle" to ensure that upon processing the > >

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Only enqueue already completed requests

2019-08-06 Thread Chris Wilson
Quoting Mika Kuoppala (2019-08-06 15:25:49) > Chris Wilson writes: > > > If we are asked to submit a completed request, just move it onto the > > active-list without modifying it's payload. > > > > If the seqno is there then there is no need to write > it yes. > > But I am not at all certain

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close

2019-08-06 Thread Chris Wilson
Quoting Bloomfield, Jon (2019-08-06 15:26:07) > > -Original Message- > > From: Chris Wilson > > + > > + /* > > + * If the user has disabled hangchecking, we can not be sure that > > + * the batches will ever complete and let the context be freed. > > + * Forcibly kill

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Mark up "sentinel" requests

2019-08-06 Thread Mika Kuoppala
Chris Wilson writes: > Sometimes we want to emit a terminator request, a request that flushes > the pipeline and allows no request to come after it. This can be used > for a "preempt-to-idle" to ensure that upon processing the > context-switch to that request, all other active contexts have been

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Only enqueue already completed requests

2019-08-06 Thread Mika Kuoppala
Chris Wilson writes: > If we are asked to submit a completed request, just move it onto the > active-list without modifying it's payload. > If the seqno is there then there is no need to write it yes. But I am not at all certain that I deduced the 'why' part correctly so please spell it out.

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close

2019-08-06 Thread Bloomfield, Jon
> -Original Message- > From: Chris Wilson > Sent: Tuesday, August 6, 2019 6:47 AM > To: intel-gfx@lists.freedesktop.org > Cc: Chris Wilson ; Joonas Lahtinen > ; Winiarski, Michal > ; Bloomfield, Jon > Subject: [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close > > Normally,

Re: [Intel-gfx] [PULL] drm-misc-next

2019-08-06 Thread Rob Herring
On Tue, Aug 6, 2019 at 1:34 AM Daniel Vetter wrote: > > On Tue, Aug 6, 2019 at 2:34 AM Dave Airlie wrote: > > > > On Sat, 3 Aug 2019 at 20:47, Maxime Ripard > > wrote: > > > > > > Hi Daniel, Dave, > > > > > > Here is the first (and pretty late) drm-misc-next PR. > > > > > > It's pretty big due

[Intel-gfx] ✓ Fi.CI.BAT: success for Send a hotplug when edid changes (rev4)

2019-08-06 Thread Patchwork
== Series Details == Series: Send a hotplug when edid changes (rev4) URL : https://patchwork.freedesktop.org/series/62816/ State : success == Summary == CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13889 Summary ---

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/tgl: Gen12 csb support

2019-08-06 Thread Chris Wilson
Quoting Mika Kuoppala (2019-08-06 15:06:09) > I remember doing a patch where we read full 64bit at a time, > as we use upper part in tracing as well on gen < 12. > Could be that Chris didn't like it. But now with doing a csb > parsing function pointer for each gen range, it could fly. Tracing

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close

2019-08-06 Thread Chris Wilson
Quoting Chris Wilson (2019-08-06 14:47:25) > +static int > +set_persistence(struct i915_gem_context *ctx, > + const struct drm_i915_gem_context_param *args) > +{ > + if (args->size) > + return -EINVAL; > + > + if (!args->value) { > +

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/tgl: Gen12 csb support

2019-08-06 Thread Mika Kuoppala
Daniele Ceraolo Spurio writes: > The CSB format has been reworked for Gen12 to include information on > both the context we're switching away from and the context we're > switching to. After the change, some of the events don't have their > own bit anymore and need to be inferred from other

Re: [Intel-gfx] [PATCH v3 0/3] Send a hotplug when edid changes

2019-08-06 Thread Lisovskiy, Stanislav
On Tue, 2019-08-06 at 15:51 +0200, Daniel Vetter wrote: > On Tue, Aug 06, 2019 at 03:55:48PM +0300, Stanislav Lisovskiy wrote: > > This series introduce to drm a way to determine if something else > > except connection_status had changed during probing, which > > can be used by other drivers as

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Send a hotplug when edid changes (rev4)

2019-08-06 Thread Patchwork
== Series Details == Series: Send a hotplug when edid changes (rev4) URL : https://patchwork.freedesktop.org/series/62816/ State : warning == Summary == $ dim checkpatch origin/drm-tip 36f82de41a75 drm: Add helper to compare edids. -:32: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Patchwork
== Series Details == Series: series starting with [CI,1/2] drm/i915/gem: Make caps.scheduler static URL : https://patchwork.freedesktop.org/series/64771/ State : success == Summary == CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13888

Re: [Intel-gfx] [PATCH v3 0/3] Send a hotplug when edid changes

2019-08-06 Thread Daniel Vetter
On Tue, Aug 06, 2019 at 03:55:48PM +0300, Stanislav Lisovskiy wrote: > This series introduce to drm a way to determine if something else > except connection_status had changed during probing, which > can be used by other drivers as well. Another i915 specific part > uses this approach to determine

[Intel-gfx] [PATCH 3/5] drm/i915: Mark up "sentinel" requests

2019-08-06 Thread Chris Wilson
Sometimes we want to emit a terminator request, a request that flushes the pipeline and allows no request to come after it. This can be used for a "preempt-to-idle" to ensure that upon processing the context-switch to that request, all other active contexts have been flushed. Signed-off-by: Chris

[Intel-gfx] [PATCH 1/5] drm/i915: Only enqueue already completed requests

2019-08-06 Thread Chris Wilson
If we are asked to submit a completed request, just move it onto the active-list without modifying it's payload. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git

[Intel-gfx] [PATCH 2/5] drm/i915/execlists: Force preemption

2019-08-06 Thread Chris Wilson
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

[Intel-gfx] [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close

2019-08-06 Thread Chris Wilson
Normally, we rely on our hangcheck to prevent persistent batches from hogging the GPU. However, if the user disables hangcheck, this mechanism breaks down. Despite our insistence that this is unsafe, the users are equally insistent that they want to use endless batches and will disable the

[Intel-gfx] [PATCH 4/5] drm/i915/execlists: Cancel banned contexts on schedule-out

2019-08-06 Thread Chris Wilson
On completion of a banned context, scrub the context image so that we do not replay the active payload. The intent is that we skip banned payloads on request submission so that the timeline advancement continues on in the background. However, if we are returning to a preempted request,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix panic if nothing to promote after preempt on reset

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: Fix panic if nothing to promote after preempt on reset URL : https://patchwork.freedesktop.org/series/64769/ State : success == Summary == CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13887

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Patchwork
== Series Details == Series: series starting with [CI,1/2] drm/i915/gem: Make caps.scheduler static URL : https://patchwork.freedesktop.org/series/64771/ State : warning == Summary == $ dim checkpatch origin/drm-tip 01c5e3f89120 drm/i915/gem: Make caps.scheduler static be2fa0bc0665

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: abstract display suspend/resume operations

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: abstract display suspend/resume operations URL : https://patchwork.freedesktop.org/series/64768/ State : success == Summary == CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13886 Summary ---

Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path

2019-08-06 Thread Josh Poimboeuf
On Mon, Aug 05, 2019 at 09:29:53PM +0200, Sedat Dilek wrote: > On Wed, Jul 31, 2019 at 2:25 PM Sedat Dilek wrote: > > > > On Fri, Jul 26, 2019 at 9:30 PM Chris Wilson > > wrote: > > > > > > Quoting Thomas Gleixner (2019-07-26 20:18:32) > > > > On Fri, 26 Jul 2019, Chris Wilson wrote: > > > > >

[Intel-gfx] [PATCH v3 3/3] drm/i915: Send hotplug event if edid had changed.

2019-08-06 Thread Stanislav Lisovskiy
Added edid checking to dp and hdmi edid setting functions, which are called from detect hooks. The result currently is propagated to calling layer using drm_connector->change_counter(proposed by Daniel Vetter). drm_helper_hpd_irq_event and intel_encoder_hotplug are currently both responsible for

[Intel-gfx] [PATCH v3 0/3] Send a hotplug when edid changes

2019-08-06 Thread Stanislav Lisovskiy
This series introduce to drm a way to determine if something else except connection_status had changed during probing, which can be used by other drivers as well. Another i915 specific part uses this approach to determine if edid had changed without changing the connection status and send a

[Intel-gfx] [PATCH v3 1/3] drm: Add helper to compare edids.

2019-08-06 Thread Stanislav Lisovskiy
Many drivers would benefit from using drm helper to compare edid, rather than bothering with own implementation. v2: Added documentation for this function. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/drm_edid.c | 33 + include/drm/drm_edid.h | 9

[Intel-gfx] [PATCH v3 2/3] drm: Introduce change counter to drm_connector

2019-08-06 Thread Stanislav Lisovskiy
This counter will be used by drm_helper_probe_detect caller to determine if something else had changed except connection status, like for example edid. Hardware specific drivers are responsible for updating this counter when some change is detected to notify the drm part, which can trigger for

[Intel-gfx] [CI 2/2] drm/i915/gt: Move the [class][inst] lookup for engines onto the GT

2019-08-06 Thread Chris Wilson
To maintain a fast lookup from a GT centric irq handler, we want the engine lookup tables on the intel_gt. To avoid having multiple copies of the same multi-dimension lookup table, move the generic user engine lookup into an rbtree (for fast and flexible indexing). v2: Split uabi_instance cf

[Intel-gfx] [CI 1/2] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Chris Wilson
We do not notify userspace when the scheduler capabilities are changed (due to wedging the driver) and as such userspace will expect the caps to be static and unchanging. Make it so, and so we only need to compute our caps once during driver registration. Signed-off-by: Chris Wilson Cc: Tvrtko

[Intel-gfx] [PATCH i-g-t] Add i915/gem_ctx_persistence

2019-08-06 Thread Chris Wilson
Sanity test existing persistence and new exciting non-persistent context behaviour. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Cc: Michał Winiarski Cc: Jon Bloomfield --- lib/i915/gem_context.c | 37 + lib/i915/gem_context.h | 9 ++ lib/ioctl_wrappers.c

Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915: Fix panic if nothing to promote after preempt on reset

2019-08-06 Thread Chris Wilson
Quoting Janusz Krzysztofik (2019-08-06 13:24:58) > Execlists state machine always falls through from PREEMPT to PROMOTE, > expecting pending to be valid. Apparently it not always happens to be > the case, at least during reset. Assuming this unexpected behavior > depends on hardware, fix the

[Intel-gfx] [RFC PATCH 1/2] drm/i915: Fix NULL pointer dereference in execlists' trace_ports()

2019-08-06 Thread Janusz Krzysztofik
If it ever happens trace_port() helper is called with NULL port 0, kernel panic occurs. Fix it. Signed-off-by: Janusz Krzysztofik --- drivers/gpu/drm/i915/gt/intel_lrc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c

[Intel-gfx] [RFC PATCH 0/2] drm/i915: Fix panic if nothing to promote after preempt on reset

2019-08-06 Thread Janusz Krzysztofik
The issue can be reproduced by interrupting "default-bomb" subtest of "gem_ringfill" IGT, at least on simulation environment which is slow. Janusz Krzysztofik (2): drm/i915: Fix NULL pointer dereference in execlists' trace_ports() drm/i915: Fix panic if nothing to promote after preempt on

[Intel-gfx] [RFC PATCH 2/2] drm/i915: Fix panic if nothing to promote after preempt on reset

2019-08-06 Thread Janusz Krzysztofik
Execlists state machine always falls through from PREEMPT to PROMOTE, expecting pending to be valid. Apparently it not always happens to be the case, at least during reset. Assuming this unexpected behavior depends on hardware, fix the issue by introducing a conditional break. Signed-off-by:

[Intel-gfx] drm/i915: always split up refactoring from functional changes!

2019-08-06 Thread Jani Nikula
Rodrigo's original patch was at v5 [1], and still stuck in discussion around the *functional* change, while 99% of the patch is *non-functional* refactoring that does not seem to be contentious. Let's do the sane thing and merge the refactoring first, shall we? BR, Jani. [1]

[Intel-gfx] [PATCH] drm/i915: abstract display suspend/resume operations

2019-08-06 Thread Jani Nikula
From: Rodrigo Vivi Increase abstraction of display suspend/resume operations by providing higher level functions, and hiding the details inside intel_display_power.c. v2: Make checkpatch happy: - braces {} are not necessary for single statement blocks v3: Also move hsw/bdw PC8 sequences

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: some more header juggling (rev3)

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: some more header juggling (rev3) URL : https://patchwork.freedesktop.org/series/64764/ State : success == Summary == CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13885 Summary ---

Re: [Intel-gfx] [PATCH] drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY

2019-08-06 Thread Jani Nikula
On Thu, 18 Jul 2019, Rodrigo Vivi wrote: > On Thu, Jul 18, 2019 at 10:25:51PM +0100, Chris Wilson wrote: >> Quoting Rodrigo Vivi (2019-07-18 22:14:45) >> > On Thu, Jul 18, 2019 at 09:58:16PM +0100, Chris Wilson wrote: >> > > Quoting Rodrigo Vivi (2019-07-18 21:49:12) >> > > > +void

Re: [Intel-gfx] [PATCH 01/22] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Mika Kuoppala
Chris Wilson writes: > Quoting Mika Kuoppala (2019-08-06 11:40:48) >> Chris Wilson writes: >> > diff --git a/drivers/gpu/drm/i915/i915_request.c >> > b/drivers/gpu/drm/i915/i915_request.c >> > index 8ac7d14ec8c9..81094f250bdb 100644 >> > --- a/drivers/gpu/drm/i915/i915_request.c >> > +++

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: some more header juggling (rev3)

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: some more header juggling (rev3) URL : https://patchwork.freedesktop.org/series/64764/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: move intel_display.c function declarations Okay! Commit:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/22] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Patchwork
== Series Details == Series: series starting with [01/22] drm/i915/gem: Make caps.scheduler static URL : https://patchwork.freedesktop.org/series/64761/ State : success == Summary == CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13884

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: some more header juggling (rev3)

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: some more header juggling (rev3) URL : https://patchwork.freedesktop.org/series/64764/ State : warning == Summary == $ dim checkpatch origin/drm-tip 38e320bf9576 drm/i915: move intel_display.c function declarations e336fea484dd drm/i915/sprite: un-inline

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dmc: Load DMC on TGL (rev2)

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915/dmc: Load DMC on TGL (rev2) URL : https://patchwork.freedesktop.org/series/64628/ State : success == Summary == CI Bug Log - changes from CI_DRM_6634_full -> Patchwork_13879_full Summary ---

[Intel-gfx] [PATCH v2] drm/i915: rename intel_drv.h to display/intel_display_types.h

2019-08-06 Thread Jani Nikula
Everything about the file is about display, and mostly about types related to display. Move under display/ as intel_display_types.h to reflect the facts. There's still plenty to clean up, but start off with moving the file where it logically belongs and naming according to contents. v2: fix the

[Intel-gfx] [PATCH v2] drm/i915/tc: un-inline intel_tc_port_ref_held()

2019-08-06 Thread Jani Nikula
Avoid including the intel_drv.h mega header from other header files to make further header cleanup easier. v2: restore the over-eagerly dropped (Imre) Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_tc.c | 7 +++ drivers/gpu/drm/i915/display/intel_tc.h | 9 ++--- 2

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: some more header juggling

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: some more header juggling URL : https://patchwork.freedesktop.org/series/64764/ State : success == Summary == CI Bug Log - changes from CI_DRM_6639 -> Patchwork_13883 Summary --- **SUCCESS**

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/22] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Patchwork
== Series Details == Series: series starting with [01/22] drm/i915/gem: Make caps.scheduler static URL : https://patchwork.freedesktop.org/series/64761/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/gem: Make caps.scheduler static Okay!

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/22] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Patchwork
== Series Details == Series: series starting with [01/22] drm/i915/gem: Make caps.scheduler static URL : https://patchwork.freedesktop.org/series/64761/ State : warning == Summary == $ dim checkpatch origin/drm-tip ff8a2db2ee62 drm/i915/gem: Make caps.scheduler static e2d0d5983bf0

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: some more header juggling

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: some more header juggling URL : https://patchwork.freedesktop.org/series/64764/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: move intel_display.c function declarations Okay! Commit: drm/i915/sprite:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: some more header juggling

2019-08-06 Thread Patchwork
== Series Details == Series: drm/i915: some more header juggling URL : https://patchwork.freedesktop.org/series/64764/ State : warning == Summary == $ dim checkpatch origin/drm-tip a6b92421ae00 drm/i915: move intel_display.c function declarations 5a0cc84ae9c6 drm/i915/sprite: un-inline

Re: [Intel-gfx] [PATCH 01/22] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Chris Wilson
Quoting Mika Kuoppala (2019-08-06 11:40:48) > Chris Wilson writes: > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index 8ac7d14ec8c9..81094f250bdb 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++

Re: [Intel-gfx] [PULL] drm-misc-next

2019-08-06 Thread Jani Nikula
On Tue, 06 Aug 2019, Emil Velikov wrote: > On Tue, 6 Aug 2019 at 11:14, Daniel Stone wrote: > >> The idea I had a few weeks ago was to have dim use 'git push >> --push-option fdo.pushedWithDim=this-was-pushed-with-dim-and-not-manually', >> then have the hooks on the server side check for that

Re: [Intel-gfx] [PATCH 01/22] drm/i915/gem: Make caps.scheduler static

2019-08-06 Thread Mika Kuoppala
Chris Wilson writes: > We do not notify userspace when the scheduler capabilities are changed > (due to wedging the driver) and as such userspace will expect the caps > to be static and unchanging. Make it so, and so we only need to compute > our caps once during driver registration. > >

Re: [Intel-gfx] [PATCH 00/10] drm/i915: some more header juggling

2019-08-06 Thread Chris Wilson
Quoting Jani Nikula (2019-08-06 11:07:21) > The big theme here is to emphasize that intel_drv.h is a display header, so > rename it display/intel_display_types.h and reduce its use in non-display > code. Also reduce the inclusion of that and the other mega header i915_drv.h > from other headers. >

Re: [Intel-gfx] [PULL] drm-misc-next

2019-08-06 Thread Emil Velikov
On Tue, 6 Aug 2019 at 11:14, Daniel Stone wrote: > The idea I had a few weeks ago was to have dim use 'git push > --push-option fdo.pushedWithDim=this-was-pushed-with-dim-and-not-manually', > then have the hooks on the server side check for that option and > refuse any direct pushes. (Or at

[Intel-gfx] [PATCH 15/22] drm/i915/gt: Convert timeline tracking to spinlock

2019-08-06 Thread Chris Wilson
Convert the list manipulation of active to use spinlocks so that we can perform the updates from underneath a quick interrupt callback. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +- drivers/gpu/drm/i915/gt/intel_reset.c| 10 --

[Intel-gfx] [PATCH 22/22] drm/i915: Markup expected timeline locks for i915_active

2019-08-06 Thread Chris Wilson
As every i915_active_request should be serialised by a dedicated lock, i915_active consists of a tree of locks; one for each node. Markup up the i915_active_request with what lock is supposed to be guarding it so that we can verify that the serialised updated are indeed serialised. Signed-off-by:

  1   2   >