[Intel-gfx] ✓ Fi.CI.IGT: success for softirq: Kick ksoftirqd if __do_softirq() is incomplete

2020-05-21 Thread Patchwork
== Series Details == Series: softirq: Kick ksoftirqd if __do_softirq() is incomplete URL : https://patchwork.freedesktop.org/series/77508/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517_full -> Patchwork_17748_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Avoid waiting inside mmu_notifier_invalidate_range

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/gem: Avoid waiting inside mmu_notifier_invalidate_range URL : https://patchwork.freedesktop.org/series/77529/ State : success == Summary == CI Bug Log - changes from CI_DRM_8523 -> Patchwork_17755

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Trace the CS interrupt (rev10)

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/gt: Trace the CS interrupt (rev10) URL : https://patchwork.freedesktop.org/series/77441/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517_full -> Patchwork_17747_full Summary ---

[Intel-gfx] [PATCH] drm/i915/gem: Avoid waiting inside mmu_notifier_invalidate_range

2020-05-21 Thread Chris Wilson
Since the userptr may be invalidated from inside a reclaim path, we cannot wait on unbinding the object as we may hold any number of locks, including the active reference of the object we are trying to invalidate. E.g. [<0>] __i915_active_wait+0x70/0xc0 [i915] [<0>] i915_vma_unbind+0x2f/0x110

Re: [Intel-gfx] [PATCH] mm/gup: fixup gup.c for "mm/gup: refactor and de-duplicate gup_fast() code"

2020-05-21 Thread Chris Wilson
c: Matthew Auld > Cc: Matthew Wilcox > Cc: Rodrigo Vivi > Cc: Souptick Joarder > Cc: Tvrtko Ursulin > Signed-off-by: John Hubbard > --- > > Hi Andrew, Chris, > > Andrew: This is a fixup that applies to today's (20200521) linux-next. > In that tree, this fixes up:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2)

2020-05-21 Thread Patchwork
== Series Details == Series: series starting with drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2) URL : https://patchwork.freedesktop.org/series/77503/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517_full -> Patchwork_17746_full

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev3)

2020-05-21 Thread Souza, Jose
On Thu, 2020-05-21 at 21:43 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev3) > URL : https://patchwork.freedesktop.org/series/77382/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_8516_full ->

Re: [Intel-gfx] [PATCH v3] drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC

2020-05-21 Thread Souza, Jose
On Wed, 2020-05-20 at 23:44 -0700, Swathi Dhanavanthri wrote: > This is a permanent w/a for JSL/EHL.This is to be applied to the > PCH types on JSL/EHL ie JSP/MCC > Bspec: 52888 > > v2: Fixed the wrong usage of logical OR(ville) > v3: Removed extra braces, changed the check(jose) > Reviewed-by:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Measure CS_TIMESTAMP (rev5)

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/selftests: Measure CS_TIMESTAMP (rev5) URL : https://patchwork.freedesktop.org/series/77320/ State : success == Summary == CI Bug Log - changes from CI_DRM_8516_full -> Patchwork_17744_full Summary

Re: [Intel-gfx] [PATCH v9 0/7] Consider DBuf bandwidth when calculating CDCLK

2020-05-21 Thread Chris Wilson
Quoting Manasi Navare (2020-05-21 22:28:42) > Pushed the series to dinq, thank you for patches and reviews Could you tidy up the mess of the merge? Things like cd19154608610ab4cdd6c039e9214b8dd281845c: --- a/drivers/gpu/drm/i915/display/intel_bw.c +++ b/drivers/gpu/drm/i915/display/intel_bw.c @@

Re: [Intel-gfx] [PATCH 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()

2020-05-21 Thread John Hubbard
On 2020-05-21 11:57, Chris Wilson wrote: Quoting John Hubbard (2020-05-19 01:21:20) This needs to go through Andrew's -mm tree, due to adding a new gup.c routine. However, I would really love to have some testing from the drm/i915 folks, because I haven't been able to run-time test that part of

[Intel-gfx] Solved: [PATCH 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()

2020-05-21 Thread John Hubbard
On 2020-05-21 12:11, John Hubbard wrote: On 2020-05-21 11:57, Chris Wilson wrote: Quoting John Hubbard (2020-05-19 01:21:20) This needs to go through Andrew's -mm tree, due to adding a new gup.c routine. However, I would really love to have some testing from the drm/i915 folks, because I

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev3)

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev3) URL : https://patchwork.freedesktop.org/series/77382/ State : success == Summary == CI Bug Log - changes from CI_DRM_8516_full -> Patchwork_17742_full

Re: [Intel-gfx] [PATCH v9 0/7] Consider DBuf bandwidth when calculating CDCLK

2020-05-21 Thread Manasi Navare
Pushed the series to dinq, thank you for patches and reviews Regards Manasi On Tue, May 19, 2020 at 04:11:10PM +0300, Stanislav Lisovskiy wrote: > We need to calculate cdclk after watermarks/ddb has been calculated > as with recent hw CDCLK needs to be adjusted accordingly to DBuf >

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Consider DBuf bandwidth when calculating CDCLK (rev18)

2020-05-21 Thread Vudum, Lakshminarayana
Stan, I have addressed the issue and re-reported. -Original Message- From: Lisovskiy, Stanislav Sent: Thursday, May 21, 2020 12:36 PM To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.IGT: failure for Consider DBuf bandwidth when calculating CDCLK

[Intel-gfx] ✓ Fi.CI.IGT: success for Consider DBuf bandwidth when calculating CDCLK (rev18)

2020-05-21 Thread Patchwork
== Series Details == Series: Consider DBuf bandwidth when calculating CDCLK (rev18) URL : https://patchwork.freedesktop.org/series/74739/ State : success == Summary == CI Bug Log - changes from CI_DRM_8511_full -> Patchwork_17733_full

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Shortcircuit queue_prio() for no internal levels

2020-05-21 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Shortcircuit queue_prio() for no internal levels URL : https://patchwork.freedesktop.org/series/77518/ State : success == Summary == CI Bug Log - changes from CI_DRM_8520 -> Patchwork_17754

Re: [Intel-gfx] [PATCH 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()

2020-05-21 Thread Chris Wilson
Quoting John Hubbard (2020-05-19 01:21:20) > This needs to go through Andrew's -mm tree, due to adding a new gup.c > routine. However, I would really love to have some testing from the > drm/i915 folks, because I haven't been able to run-time test that part > of it. CI hit <4> [185.667750]

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Stop cross-poluting PIN_GLOBAL with PIN_USER with no-ppgtt

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/gt: Stop cross-poluting PIN_GLOBAL with PIN_USER with no-ppgtt URL : https://patchwork.freedesktop.org/series/77517/ State : success == Summary == CI Bug Log - changes from CI_DRM_8520 -> Patchwork_17753

[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce DG1

2020-05-21 Thread Patchwork
== Series Details == Series: Introduce DG1 URL : https://patchwork.freedesktop.org/series/77496/ State : success == Summary == CI Bug Log - changes from CI_DRM_8515_full -> Patchwork_17740_full Summary --- **WARNING** Minor

[Intel-gfx] [PATCH 2/2] drm/i915: Improve execute_cb struct packing

2020-05-21 Thread Chris Wilson
Reduce the irq_work llist for attaching the callbacks to the signal for both smaller structs (two fewer pointers!) and simpler [debug] code: Function old new delta irq_execute_cb35 34 -1

[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Shortcircuit queue_prio() for no internal levels

2020-05-21 Thread Chris Wilson
If there are no internal levels and the user priority-shift is zero, we can help the compiler eliminate some dead code: Function old new delta start_timeslice 169 154 -15 __execlists_submission_tasklet

Re: [Intel-gfx] [PATCH 08/37] drm/i915: make intel_{uncore, de}_rmw() more useful

2020-05-21 Thread Lucas De Marchi
On Thu, May 21, 2020 at 10:24:49AM -0700, Jose Souza wrote: On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote: Return the old value read so some places of the code can still do the rmw but add warnings/errors about the value it read. Signed-off-by: Lucas De Marchi ---

Re: [Intel-gfx] [PATCH 08/37] drm/i915: make intel_{uncore, de}_rmw() more useful

2020-05-21 Thread Souza, Jose
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote: > Return the old value read so some places of the code can still do the > rmw but add warnings/errors about the value it read. > > Signed-off-by: Lucas De Marchi > --- > drivers/gpu/drm/i915/display/intel_de.h | 4 ++-- >

[Intel-gfx] [PATCH] drm/i915/gt: Stop cross-poluting PIN_GLOBAL with PIN_USER with no-ppgtt

2020-05-21 Thread Chris Wilson
In order to keep userptr distinct from ggtt mmaps in the eyes of lockdep, we need to avoid marking those userptr vma as PIN_GLOBAL. (So long as we comply with only using them as local PIN_USER!) References: https://gitlab.freedesktop.org/drm/intel/-/issues/1880 Signed-off-by: Chris Wilson ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove PIN_UPDATE for i915_vma_pin

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915: Remove PIN_UPDATE for i915_vma_pin URL : https://patchwork.freedesktop.org/series/77515/ State : success == Summary == CI Bug Log - changes from CI_DRM_8518 -> Patchwork_17752 Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing

2020-05-21 Thread Patchwork
== Series Details == Series: series starting with [CI,1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing URL : https://patchwork.freedesktop.org/series/77512/ State : success == Summary == CI Bug Log - changes from CI_DRM_8518 -> Patchwork_17751

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add psr_safest_params

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915: Add psr_safest_params URL : https://patchwork.freedesktop.org/series/77491/ State : success == Summary == CI Bug Log - changes from CI_DRM_8515_full -> Patchwork_17738_full Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing

2020-05-21 Thread Patchwork
== Series Details == Series: series starting with [CI,1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing URL : https://patchwork.freedesktop.org/series/77512/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_nop: Specify timeout in milliseconds

2020-05-21 Thread Janusz Krzysztofik
On Tue, 2020-05-12 at 18:19 +0100, Chris Wilson wrote: > Our 'headless' subtest requires fairly precise measurements to determine > the impact of the dmc upon request latency. The test cannot be effective > if we cannot execute requests quickly, so add a very short pre-pass to > check the test

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Cancel the flush worker more thoroughly

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/gt: Cancel the flush worker more thoroughly URL : https://patchwork.freedesktop.org/series/77490/ State : success == Summary == CI Bug Log - changes from CI_DRM_8515_full -> Patchwork_17736_full

[Intel-gfx] [CI] drm/i915: Remove PIN_UPDATE for i915_vma_pin

2020-05-21 Thread Chris Wilson
As we no longer use PIN_UPDATE (since commit 7d0aa0db4375 ("drm/i915/gem: Unbind all current vma on changing cache-level")) we can remove PIN_UPDATE itself. The benefit is just in simplifing the vma bind. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ---

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove PIN_UPDATE for i915_vma_pin

2020-05-21 Thread Matthew Auld
On Sat, 16 May 2020 at 18:07, Chris Wilson wrote: > > As we no longer use PIN_UPDATE (since commit 7d0aa0db4375 ("drm/i915/gem: > Unbind all current vma on changing cache-level")) we can remove > PIN_UPDATE itself. The benefit is just in simplifing the vma bind. > > Signed-off-by: Chris Wilson

[Intel-gfx] [CI 2/2] drm/i915: Avoid using rq->engine after free during i915_fence_release

2020-05-21 Thread Chris Wilson
In order to be valid to dereference during the i915_fence_release, after retiring the fence and releasing its refererences, we assume that rq->engine can only be a real engine (that stay intact until the device is shutdown after all fences have been flushed). However, due to a quirk of

[Intel-gfx] [CI 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing

2020-05-21 Thread Chris Wilson
Since the removal of the no-semaphore boosting, we rely on timeslicing to reorder passed inter-dependency hogs across the engines. However, we require preemption to support timeslicing into user payloads, and not all machine support preemption so we do not universally enable timeslicing, even when

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing

2020-05-21 Thread Tvrtko Ursulin
On 21/05/2020 11:17, Chris Wilson wrote: Quoting Chris Wilson (2020-05-21 10:42:26) Quoting Tvrtko Ursulin (2020-05-21 10:10:10) On 21/05/2020 09:53, Chris Wilson wrote: Since the remove of the no-semaphore boosting, we rely on timeslicing to reorder past inter-dependency hogs across the

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Avoid using rq->engine after free during i915_fence_release

2020-05-21 Thread Tvrtko Ursulin
On 21/05/2020 10:44, Chris Wilson wrote: Quoting Chris Wilson (2020-05-21 10:32:49) Quoting Chris Wilson (2020-05-21 10:27:16) Quoting Tvrtko Ursulin (2020-05-21 10:13:14) On 21/05/2020 09:53, Chris Wilson wrote: In order to be valid to dereference during the i915_fence_release, after

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Flush the submission, not cancel it!

2020-05-21 Thread Tvrtko Ursulin
On 21/05/2020 13:43, Chris Wilson wrote: Use intel_engine_flush_submission() when we want to ensure that the tasklet is run. tasklet_kill(), while it may ensure that an ongoing tasklet is completed, also prevents the tasklet from running if it's already scheduled and hasn't yet been run.

Re: [Intel-gfx] [PATCH] drm/i915/hdcp: Avoid duplicate HDCP enables

2020-05-21 Thread Sean Paul
On Thu, May 21, 2020 at 5:36 AM Anshuman Gupta wrote: > > On 2020-05-21 at 10:27:21 +0530, Ramalingam C wrote: > > On 2020-05-20 at 15:47:44 -0400, Sean Paul wrote: > > > From: Sean Paul > > > > > > If userspace sets the CP property to DESIRED while it's already ENABLED, > > > the driver will

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Flush the submission, not cancel it!

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/selftests: Flush the submission, not cancel it! URL : https://patchwork.freedesktop.org/series/77510/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17750 Summary

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Immediately check for ACK after submission

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/gt: Immediately check for ACK after submission URL : https://patchwork.freedesktop.org/series/77509/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17749 Summary

[Intel-gfx] [PATCH] drm/i915/selftests: Flush the submission, not cancel it!

2020-05-21 Thread Chris Wilson
Use intel_engine_flush_submission() when we want to ensure that the tasklet is run. tasklet_kill(), while it may ensure that an ongoing tasklet is completed, also prevents the tasklet from running if it's already scheduled and hasn't yet been run. Closes:

[Intel-gfx] [PATCH] drm/i915/gt: Immediately check for ACK after submission

2020-05-21 Thread Chris Wilson
In an extreme case this may reduce the ACK latency by handling the immediate HW response from a ready engine. That reduction in latency should not actually impact any submission latency since on the direct submit path we try and clear any pending interrupts first. On the indirect reprioritisation

[Intel-gfx] ✓ Fi.CI.BAT: success for softirq: Kick ksoftirqd if __do_softirq() is incomplete

2020-05-21 Thread Patchwork
== Series Details == Series: softirq: Kick ksoftirqd if __do_softirq() is incomplete URL : https://patchwork.freedesktop.org/series/77508/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17748 Summary

[Intel-gfx] [PATCH] softirq: Kick ksoftirqd if __do_softirq() is incomplete

2020-05-21 Thread Chris Wilson
When invoking the softirq, a tasklet may be skipped due to contention or being disabled. The tasklet is then left on the scheduled list, but we do not wakeup ksoftirqd to retry the execution. Signed-off-by: Chris Wilson --- kernel/softirq.c | 5 +++-- 1 file changed, 3 insertions(+), 2

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Trace the CS interrupt (rev10)

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/gt: Trace the CS interrupt (rev10) URL : https://patchwork.freedesktop.org/series/77441/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17747 Summary ---

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Exercise stalls of bonded pairs

2020-05-21 Thread Chris Wilson
Broadwell doesn't allow preemption and so a request must complete within a hangcheck period or be declared hung. A bonded request may be submitted before it's master is ready to run, and if preemption is disabled there is a danger that wait may be charged against the bond, rather than the culprit

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2)

2020-05-21 Thread Patchwork
== Series Details == Series: series starting with drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2) URL : https://patchwork.freedesktop.org/series/77503/ State : success == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17746

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing

2020-05-21 Thread Chris Wilson
Quoting Chris Wilson (2020-05-21 10:42:26) > Quoting Tvrtko Ursulin (2020-05-21 10:10:10) > > > > On 21/05/2020 09:53, Chris Wilson wrote: > > > Since the remove of the no-semaphore boosting, we rely on timeslicing to > > > reorder past inter-dependency hogs across the engines. However, we > > >

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2)

2020-05-21 Thread Patchwork
== Series Details == Series: series starting with drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2) URL : https://patchwork.freedesktop.org/series/77503/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Trace the CS interrupt (rev9)

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/gt: Trace the CS interrupt (rev9) URL : https://patchwork.freedesktop.org/series/77441/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8517 -> Patchwork_17745 Summary ---

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Avoid using rq->engine after free during i915_fence_release

2020-05-21 Thread Chris Wilson
Quoting Chris Wilson (2020-05-21 10:32:49) > Quoting Chris Wilson (2020-05-21 10:27:16) > > Quoting Tvrtko Ursulin (2020-05-21 10:13:14) > > > > > > On 21/05/2020 09:53, Chris Wilson wrote: > > > > In order to be valid to dereference during the i915_fence_release, after > > > > retiring the fence

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing

2020-05-21 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-05-21 10:10:10) > > On 21/05/2020 09:53, Chris Wilson wrote: > > Since the remove of the no-semaphore boosting, we rely on timeslicing to > > reorder past inter-dependency hogs across the engines. However, we > > require preemption to support timeslicing into user

Re: [Intel-gfx] [PATCH] drm/i915/hdcp: Avoid duplicate HDCP enables

2020-05-21 Thread Anshuman Gupta
On 2020-05-21 at 10:27:21 +0530, Ramalingam C wrote: > On 2020-05-20 at 15:47:44 -0400, Sean Paul wrote: > > From: Sean Paul > > > > If userspace sets the CP property to DESIRED while it's already ENABLED, > > the driver will try to re-enable HDCP. On some displays, this will > > result in R0'

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Consider DBuf bandwidth when calculating CDCLK (rev18)

2020-05-21 Thread Lisovskiy, Stanislav
Seems to be unrelated issue. There seems to be some list corruption happening in drm fb manipulation code. if those patches would be causing that (like some severe mem corruption)- it would happen much more broadly than single test and single platform. Moreover there is no direct connection to

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Avoid using rq->engine after free during i915_fence_release

2020-05-21 Thread Chris Wilson
Quoting Chris Wilson (2020-05-21 10:27:16) > Quoting Tvrtko Ursulin (2020-05-21 10:13:14) > > > > On 21/05/2020 09:53, Chris Wilson wrote: > > > In order to be valid to dereference during the i915_fence_release, after > > > retiring the fence and releasing its refererences, we assume that > > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Avoid using rq->engine after free during i915_fence_release

2020-05-21 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-05-21 10:13:14) > > On 21/05/2020 09:53, Chris Wilson wrote: > > In order to be valid to dereference during the i915_fence_release, after > > retiring the fence and releasing its refererences, we assume that > > rq->engine can only be a real engine (that stay intact

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Avoid using rq->engine after free during i915_fence_release

2020-05-21 Thread Tvrtko Ursulin
On 21/05/2020 09:53, Chris Wilson wrote: In order to be valid to dereference during the i915_fence_release, after retiring the fence and releasing its refererences, we assume that rq->engine can only be a real engine (that stay intact until the device is shutdown after all fences have been

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing

2020-05-21 Thread Tvrtko Ursulin
On 21/05/2020 09:53, Chris Wilson wrote: Since the remove of the no-semaphore boosting, we rely on timeslicing to reorder past inter-dependency hogs across the engines. However, we require preemption to support timeslicing into user payloads, and not all machine support preemption so we do not

[Intel-gfx] [PATCH] drm/i915: Disable semaphore inter-engine sync without timeslicing

2020-05-21 Thread Chris Wilson
Since the removal of the no-semaphore boosting, we rely on timeslicing to reorder passed inter-dependency hogs across the engines. However, we require preemption to support timeslicing into user payloads, and not all machine support preemption so we do not universally enable timeslicing, even when

[Intel-gfx] [PATCH 2/2] drm/i915: Avoid using rq->engine after free during i915_fence_release

2020-05-21 Thread Chris Wilson
In order to be valid to dereference during the i915_fence_release, after retiring the fence and releasing its refererences, we assume that rq->engine can only be a real engine (that stay intact until the device is shutdown after all fences have been flushed). However, due to a quirk of

[Intel-gfx] [PATCH 1/2] drm/i915: Disable semaphore inter-engine sync without timeslicing

2020-05-21 Thread Chris Wilson
Since the remove of the no-semaphore boosting, we rely on timeslicing to reorder past inter-dependency hogs across the engines. However, we require preemption to support timeslicing into user payloads, and not all machine support preemption so we do not universally enable timeslicing even when it

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Measure CS_TIMESTAMP (rev5)

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/selftests: Measure CS_TIMESTAMP (rev5) URL : https://patchwork.freedesktop.org/series/77320/ State : success == Summary == CI Bug Log - changes from CI_DRM_8516 -> Patchwork_17744 Summary ---

Re: [Intel-gfx] [PATCH 26/37] drm/i915/dg1: Handle GRF/IC ECC error irq

2020-05-21 Thread Chris Wilson
Quoting Lucas De Marchi (2020-05-21 01:37:52) > From: Fernando Pacheco > > The error detection and correction capability > for GRF and instruction cache (IC) will utilize > the new interrupt and error handling infrastructure > for dgfx products. The GFX device can generate > a number of classes

Re: [Intel-gfx] [PATCH 10/37] drm/i915: add pcie snoop flag

2020-05-21 Thread Chris Wilson
Quoting Lucas De Marchi (2020-05-21 01:37:36) > From: Matthew Auld > > Gen 12 dgfx devices are coherent with system memory even over PCIe. > Therefore supporting coherent userptr should be possible. Then set has-snoop with a comment that it is over PCIe. This patch only covers one

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Measure CS_TIMESTAMP (rev5)

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/selftests: Measure CS_TIMESTAMP (rev5) URL : https://patchwork.freedesktop.org/series/77320/ State : warning == Summary == $ dim checkpatch origin/drm-tip f49741c69378 drm/i915/selftests: Measure CS_TIMESTAMP -:68: CHECK:USLEEP_RANGE: usleep_range is

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Trace the CS interrupt (rev8)

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/gt: Trace the CS interrupt (rev8) URL : https://patchwork.freedesktop.org/series/77441/ State : success == Summary == CI Bug Log - changes from CI_DRM_8516 -> Patchwork_17743 Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev3)

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev3) URL : https://patchwork.freedesktop.org/series/77382/ State : success == Summary == CI Bug Log - changes from CI_DRM_8516 -> Patchwork_17742 Summary

[Intel-gfx] [CI] drm/i915/selftests: Measure CS_TIMESTAMP

2020-05-21 Thread Chris Wilson
Count the number of CS_TIMESTAMP ticks and check that it matches our expectations. Signed-off-by: Chris Wilson Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 132 +++ 1 file changed, 132 insertions(+) diff --git

[Intel-gfx] ✗ Fi.CI.IGT: failure for Consider DBuf bandwidth when calculating CDCLK (rev18)

2020-05-21 Thread Patchwork
== Series Details == Series: Consider DBuf bandwidth when calculating CDCLK (rev18) URL : https://patchwork.freedesktop.org/series/74739/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8511_full -> Patchwork_17733_full

[Intel-gfx] [PATCH v3] drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC

2020-05-21 Thread Swathi Dhanavanthri
This is a permanent w/a for JSL/EHL.This is to be applied to the PCH types on JSL/EHL ie JSP/MCC Bspec: 52888 v2: Fixed the wrong usage of logical OR(ville) v3: Removed extra braces, changed the check(jose) Signed-off-by: Swathi Dhanavanthri --- drivers/gpu/drm/i915/i915_irq.c | 6 -- 1

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev10)

2020-05-21 Thread Patchwork
== Series Details == Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev10) URL : https://patchwork.freedesktop.org/series/73036/ State : success == Summary == CI Bug Log - changes from CI_DRM_8511_full -> Patchwork_17732_full