[Intel-gfx] [PATCH 21/37] drm/i915/dg1: Add and setup DPLLs for DG1

From: Aditya Swarup Add entries for dg1 plls and setup dg1_pll_mgr to reuse icl callbacks. Initial setup for shared dplls DPLL0/1 for DDIA/B and DPLL2/3 for DDIC/D. Configure dpll cfgcrx registers to drive the plls on DG1. Signed-off-by: Aditya Swarup Signed-off-by: Lucas De Marchi ---

[Intel-gfx] [PATCH 13/37] drm/i915/dg1: Add fake PCH

DG1 has the south engine display on the same PCI device. Ideally we could use HAS_PCH_SPLIT(), but that macro is used all across the code base to rather signify a range of gens. So add a fake one for DG1 to be used where needed. Cc: Aditya Swarup Signed-off-by: Lucas De Marchi ---

[Intel-gfx] [PATCH 20/37] drm/i915/dg1: Add DPLL macros for DG1

From: Aditya Swarup DG1 has 4 DPLLs where DPLL0 and DPLL1 drive DDIA/B and DPLL2 and DPLL3 drive DDIC/DDID. Introduce DG1_DPLL_CFCRx() helper macros to configure DPLL registers. Bspec: 50288, 50299 Cc: Matt Roper Signed-off-by: Aditya Swarup Signed-off-by: Lucas De Marchi ---

[Intel-gfx] [PATCH 04/37] drm/i915/rkl: provide port/phy mapping for vbt

RKL uses the DDI A, DDI B, DDI USBC1, DDI USBC2 from the DE point of view, so all DDI/pipe/transcoder register use these indexes to refer to them. Combo phy and IO functions follow another namespace that we keep as "enum phy". The VBT in theory would use the DE point of view, but that does not

[Intel-gfx] [PATCH 34/37] drm/i915/dg1: enable PORT C/D aka D/E

For DG1 we have a little of mix up wrt to DDI/port names and indexes. Bspec refers to the ports as DDIA, DDIB, DDI USBC1 and DDI USBC2 (besides the DDIA, DDIB, DDIC, DDID), but the previous naming is the most unambiguous one. This means that for any register on Display Engine we should use the

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

From: Matthew Auld Gen 12 dgfx devices are coherent with system memory even over PCIe. Therefore supporting coherent userptr should be possible. Cc: Stuart Summers Signed-off-by: Matthew Auld Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 ++-

[Intel-gfx] [PATCH 30/37] drm/i915/dg1: Update comp master/slave relationships for PHYs

From: Matt Roper As with RKL, DG1's PHY C acts as a comp master for PHY D. Bspec: 49291 Signed-off-by: Matt Roper Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH 09/37] drm/i915: Add has_master_unit_irq flag

From: Stuart Summers Add flag to differentiate platforms with and without the master IRQ control bit. Signed-off-by: Stuart Summers Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_device_info.h | 1 + 2 files changed, 3

[Intel-gfx] [PATCH 35/37] drm/i915/dg1: Load DMC

From: Matt Atwood Add support to load DMC v2.0.2 on DG1 While we're at it, tweak the TGL and RKL firmware size definition to follow the convention used in previous platforms. Remove obsolete commenting. Bpec: 49230 Cc: Matt Roper Signed-off-by: Matt Atwood Signed-off-by: Lucas De Marchi

[Intel-gfx] [PATCH 01/37] drm/i915/rkl: Add DPLL4 support

From: Matt Roper Rocket Lake has a third DPLL (called 'DPLL4') that must be used to enable a third display. Unlike EHL's variant of DPLL4, the RKL variant behaves the same as DPLL0/1. And despite its name, the DPLL4 registers are offset as if it were DPLL2, so no extra offset handling is

[Intel-gfx] [PATCH 27/37] drm/i915/dg1: Log counter on SLM ECC error

From: Fernando Pacheco Correctable and uncorrectable Shared Local Memory (SLM) ECC errors will be counted in two different Thread Dispatch Logic (TDL) registers. GuC will receive a message from TDL when the first correctable/uncorrectable error is detected by SLM (first after a reset or register

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

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' mismatches. I'm guessing this is because the display is > still

Re: [Intel-gfx] [PATCH v2] drm/i915/hdcp: Add additional R0' wait

On 2020-05-20 at 15:50:15 -0400, Sean Paul wrote: > On Wed, May 20, 2020 at 9:08 AM Sean Paul wrote: > > > > From: Sean Paul > > > > We're seeing some R0' mismatches in the field, particularly with > > repeaters. I'm guessing the (already lenient) 300ms wait time isn't > > enough for some

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce DG1

== Series Details == Series: Introduce DG1 URL : https://patchwork.freedesktop.org/series/77496/ State : warning == Summary == $ dim checkpatch origin/drm-tip eb8bcc051bcb drm/i915/rkl: Add DPLL4 support 8eb7430370e7 drm/i915/rkl: Add DDC pin mapping 470f943d8711 drm/i915/rkl: Setup

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce DG1

== Series Details == Series: Introduce DG1 URL : https://patchwork.freedesktop.org/series/77496/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. -

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

== Series Details == Series: Introduce DG1 URL : https://patchwork.freedesktop.org/series/77496/ State : success == Summary == CI Bug Log - changes from CI_DRM_8515 -> Patchwork_17740 Summary --- **SUCCESS** No regressions found.

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/params: don't expose inject_probe_failure in debugfs (rev2)

== Series Details == Series: series starting with [1/3] drm/i915/params: don't expose inject_probe_failure in debugfs (rev2) URL : https://patchwork.freedesktop.org/series/77366/ State : success == Summary == CI Bug Log - changes from CI_DRM_8511_full -> Patchwork_17728_full

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Replace deprecated function in drm_crtc_helper

== Series Details == Series: drm: Replace deprecated function in drm_crtc_helper URL : https://patchwork.freedesktop.org/series/77467/ State : success == Summary == CI Bug Log - changes from CI_DRM_8511_full -> Patchwork_17729_full Summary

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hdcp: Add additional R0' wait (rev2)

== Series Details == Series: drm/i915/hdcp: Add additional R0' wait (rev2) URL : https://patchwork.freedesktop.org/series/77439/ State : success == Summary == CI Bug Log - changes from CI_DRM_8511_full -> Patchwork_17731_full Summary

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hdcp: Avoid duplicate HDCP enables (rev2)

== Series Details == Series: drm/i915/hdcp: Avoid duplicate HDCP enables (rev2) URL : https://patchwork.freedesktop.org/series/77487/ State : failure == Summary == Applying: drm/i915/hdcp: Avoid duplicate HDCP enables error: patch failed: drivers/gpu/drm/drm_atomic_uapi.c:746 error:

Re: [Intel-gfx] [PATCH] drm/i915/hdcp: Add additional R0' wait

On 2020-05-19 at 18:16:21 -0400, Sean Paul wrote: > From: Sean Paul > > We're seeing some R0' mismatches in the field, particularly with I think you want to say Vprime verification? delay is added in between the retry for vprime verfication. -Ram > repeaters. I'm guessing the (already lenient)

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

Self test failure as usual. And as usual not related to the patch. Best Regards, Lisovskiy Stanislav From: Patchwork Sent: Wednesday, May 20, 2020 2:59 AM To: Lisovskiy, Stanislav Cc: intel-gfx@lists.freedesktop.org Subject: ✗ Fi.CI.BAT: failure for

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

Count the number of CS_TIMESTAMP ticks and check that it matches our expectations. v2: Double read the TIMESTAMP as there is a tendency for it to stick on older HW. Signed-off-by: Chris Wilson Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 115

Re: [Intel-gfx] [PATCH] dma-fence: add might_sleep annotation to _wait()

Am 19.05.20 um 15:27 schrieb Daniel Vetter: Do it uncontionally, there's a separate peek function with dma_fence_is_signalled() which can be called from atomic context. v2: Consensus calls for an unconditional might_sleep (Chris, Christian) Full audit: - dma-fence.h: Uses MAX_SCHEDULE_TIMOUT,

[Intel-gfx] [PATCH] drm/i915/gt: Remove errant assertion in __intel_context_do_pin

This assertion was removed in b412c63f1cba ("drm/i915/gt: Report context-is-closed prior to pinning"), but accidentally restored by a cherry-pick into drm-next and now has percolated back to drm-intel-next-queued. Fixes: 2e46a2a0b014 ("drm/i915: Use explicit flag to mark unreachable

[Intel-gfx] [PATCH 06/22] drm/i915/gt: Decouple inflight virtual engines

Once a virtual engine has been bound to a sibling, it will remain bound until we finally schedule out the last active request. We can not rebind the context to a new sibling while it is inflight as the context save will conflict, hence we wait. As we cannot then use any other sibliing while the

[Intel-gfx] [PATCH 20/22] drm/i915/gem: Asynchronous GTT unbinding

It is reasonably common for userspace (even modern drivers like iris) to reuse an active address for a new buffer. This would cause the application to stall under its mutex (originally struct_mutex) until the old batches were idle and it could synchronously remove the stale PTE. However, we can

[Intel-gfx] [PATCH 17/22] drm/i915/gem: Assign context id for async work

Allocate a few dma fence context id that we can use to associate async work [for the CPU] launched on behalf of this context. For extra fun, we allow a configurable concurrency width. A current example would be that we spawn an unbound worker for every userptr get_pages. In the future, we wish to

[Intel-gfx] [PATCH 21/22] drm/i915/gem: Bind the fence async for execbuf

It is illegal to wait on an another vma while holding the vm->mutex, as that easily leads to ABBA deadlocks (we wait on a second vma that waits on us to release the vm->mutex). So while the vm->mutex exists, move the waiting outside of the lock into the async binding pipeline. Signed-off-by:

[Intel-gfx] [PATCH 04/22] drm/i915: Move saturated workload detection back to the context

When we introduced the saturated workload detection to tell us to back off from semaphore usage [semaphores have a noticeable impact on contended bus cycles with the CPU for some heavy workloads], we first introduced it as a per-context tracker. This allows individual contexts to try and optimise

[Intel-gfx] [PATCH 10/22] drm/syncobj: Allow use of dma-fence-proxy

Allow the callers to supply a dma-fence-proxy for asynchronous waiting on future fences. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_syncobj.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index

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

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 16/22] drm/i915: Always defer fenced work to the worker

Currently, if an error is raised we always call the cleanup locally [and skip the main work callback]. However, some future users may need to take a mutex to cleanup and so we cannot immediately execute the cleanup as we may still be in interrupt context. With the execute-immediate flag, for most

[Intel-gfx] [PATCH 19/22] drm/i915/gem: Separate the ww_mutex walker into its own list

In preparation for making eb_vma bigger and heavy to run inn parallel, we need to stop apply an in-place swap() to reorder around ww_mutex deadlocks. Keep the array intact and reorder the locks using a dedicated list. Signed-off-by: Chris Wilson --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c

[Intel-gfx] [PATCH 09/22] dma-buf: Proxy fence, an unsignaled fence placeholder

Often we need to create a fence for a future event that has not yet been associated with a fence. We can store a proxy fence, a placeholder, in the timeline and replace it later when the real fence is known. Any listeners that attach to the proxy fence will automatically be signaled when the real

[Intel-gfx] [PATCH 05/22] drm/i915/gt: Use virtual_engine during execlists_dequeue

Rather than going back and forth between the rb_node entry and the virtual_engine type, store the ve local and reuse it. As the container_of conversion from rb_node to virtual_engine requires a variable offset, performing that conversion just once shaves off a bit of code. v2: Keep a single

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

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 12/22] drm/i915/gem: Allow combining submit-fences with syncobj

We allow exported sync_file fences to be used as submit fences, but they are not the only source of user fences. We also accept an array of syncobj, and as with sync_file these are dma_fences underneath and so feature the same set of controls. The submit-fence allows for a request to be scheduled

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

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

[Intel-gfx] [PATCH 13/22] drm/i915/gt: Declare when we enabled timeslicing

Let userspace know if they can trust timeslicing by including it as part of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING v2: Only declare timeslicing if we can safely preempt userspace. Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing") Link:

[Intel-gfx] [PATCH 14/22] drm/i915/gt: Use built-in active intel_context reference

Since a few rearragements ago, we have an explicit reference to the containing intel_context from inside the active reference and can drop our own reference handling dancing around releasing the i915_active. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_context.c | 8 1

[Intel-gfx] [PATCH 11/22] drm/i915/gem: Teach execbuf how to wait on future syncobj

If a syncobj has not yet been assigned, treat it as a future fence and install and wait upon a dma-fence-proxy. The proxy will be replace by the real fence later, and that fence will be responsible for signaling our waiter. Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4854

[Intel-gfx] [PATCH 22/22] drm/i915: Micro-optimise i915_request_completed()

This is primarily focused on reducing the number of lockdep checks we endure in CI, as each i915_request_completed() takes the rcu_read_lock() and we use i915_request_completed() very, very frequently. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 11 +++---

[Intel-gfx] [PATCH 15/22] drm/i915: Drop I915_IDLE_ENGINES_TIMEOUT

This timeout is only used in one place, to provide a tiny bit of grace for slow igt to cleanup after themselves. If we are a bit stricter and opt to kill outstanding requsts rather than wait, we can speed up igt by not waiting for 200ms after a hang. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 07/22] drm/i915/gt: Resubmit the virtual engine on schedule-out

Having recognised that we do not change the sibling until we schedule out, we can then defer the decision to resubmit the virtual engine from the unwind of the active queue to scheduling out of the virtual context. By keeping the unwind order intact on the local engine, we can preserve data

[Intel-gfx] [PATCH 18/22] drm/i915: Export a preallocate variant of i915_active_acquire()

Sometimes we have to be very careful not to allocate underneath a mutex (or spinlock) and yet still want to track activity. Enter i915_active_acquire_for_context(). This raises the activity counter on i915_active prior to use and ensures that the fence-tree contains a slot for the context.

[Intel-gfx] [PATCH 01/22] drm/i915/gem: Suppress some random warnings

Leave the error propagation in place, but limit the warnings to only show up in CI if the unlikely errors are hit. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 3 +-- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 3 +--

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Remove errant assertion in __intel_context_do_pin

== Series Details == Series: drm/i915/gt: Remove errant assertion in __intel_context_do_pin URL : https://patchwork.freedesktop.org/series/77448/ State : failure == Summary == Applying: drm/i915/gt: Remove errant assertion in __intel_context_do_pin Using index info to reconstruct a base

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

== Series Details == Series: drm/i915/gt: Trace the CS interrupt (rev2) URL : https://patchwork.freedesktop.org/series/77441/ State : success == Summary == CI Bug Log - changes from CI_DRM_8509 -> Patchwork_17721 Summary ---

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

== Series Details == Series: Consider DBuf bandwidth when calculating CDCLK (rev15) URL : https://patchwork.freedesktop.org/series/74739/ State : success == Summary == CI Bug Log - changes from CI_DRM_8506 -> Patchwork_17718 Summary

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Measure CS_TIMESTAMP (rev4)

== Series Details == Series: drm/i915/selftests: Measure CS_TIMESTAMP (rev4) URL : https://patchwork.freedesktop.org/series/77320/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8509 -> Patchwork_17723 Summary ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/22] drm/i915/gem: Suppress some random warnings

== Series Details == Series: series starting with [01/22] drm/i915/gem: Suppress some random warnings URL : https://patchwork.freedesktop.org/series/77459/ State : warning == Summary == $ dim checkpatch origin/drm-tip 35b35b313bad drm/i915/gem: Suppress some random warnings -:62:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/22] drm/i915/gem: Suppress some random warnings

== Series Details == Series: series starting with [01/22] drm/i915/gem: Suppress some random warnings URL : https://patchwork.freedesktop.org/series/77459/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked

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

Filed a new bug and Re-reported. -Original Message- From: Lisovskiy, Stanislav Sent: Wednesday, May 20, 2020 9:22 AM To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana ; Saarinen, Jani ; Navare, Manasi D Subject: Re: ✗ Fi.CI.BAT: failure for Consider DBuf bandwidth when

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

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] [PATCH] drm/i915: Disable semaphore inter-engine sync without timeslicing

Since the remove of the no-semaphore boosting, we rely on timeslicing to reorder past inter-dependency hogs across the engines. However, if we require preemption to support timeslicing, and not all machine support preemption. Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw Fixes:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Neuter virtual rq->engine on retire

== Series Details == Series: drm/i915: Neuter virtual rq->engine on retire URL : https://patchwork.freedesktop.org/series/77425/ State : success == Summary == CI Bug Log - changes from CI_DRM_8506_full -> Patchwork_17714_full Summary

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

== Series Details == Series: drm/i915/selftests: Measure CS_TIMESTAMP (rev4) URL : https://patchwork.freedesktop.org/series/77320/ State : warning == Summary == $ dim checkpatch origin/drm-tip d4d9394cab86 drm/i915/selftests: Measure CS_TIMESTAMP -:72: CHECK:USLEEP_RANGE: usleep_range is

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/22] drm/i915/gem: Suppress some random warnings

== Series Details == Series: series starting with [01/22] drm/i915/gem: Suppress some random warnings URL : https://patchwork.freedesktop.org/series/77459/ State : success == Summary == CI Bug Log - changes from CI_DRM_8509 -> Patchwork_17724

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

Thank you Lakshmi! Best Regards, Lisovskiy Stanislav Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo From: Vudum, Lakshminarayana Sent: Wednesday, May 20, 2020 11:43:26 AM To: Lisovskiy, Stanislav;

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

== Series Details == Series: drm/i915/gt: Trace the CS interrupt (rev3) URL : https://patchwork.freedesktop.org/series/77441/ State : success == Summary == CI Bug Log - changes from CI_DRM_8509 -> Patchwork_17725 Summary ---

Re: [Intel-gfx] [PATCH v2 02/22] x86/gpu: add RKL stolen memory support

On Tue, May 19, 2020 at 04:57:27PM -0700, Lucas De Marchi wrote: > The following files are outside of i915 maintenance scope: > arch/x86/kernel/early-quirks.c > > Can we get an ack? Acked-by: Borislav Petkov > Going forward, for simple changes like this, do you prefer to still > ack on it or

[Intel-gfx] [PATCH i-g-t] tools/intel_gpu_top: Include total package power

With integrated graphics the TDP is shared between the gpu and the cpu, knowing the total energy consumed by the package is relevant to understanding throttling. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- tools/intel_gpu_top.c | 195 -- 1 file

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

== Series Details == Series: drm/i915: Disable semaphore inter-engine sync without timeslicing (rev2) URL : https://patchwork.freedesktop.org/series/77462/ State : success == Summary == CI Bug Log - changes from CI_DRM_8509 -> Patchwork_17726

Re: [Intel-gfx] [PATCH] drm/i915/gt: Remove errant assertion in __intel_context_do_pin

Quoting Chris Wilson (2020-05-20 10:30:48) > This assertion was removed in b412c63f1cba ("drm/i915/gt: Report > context-is-closed prior to pinning"), but accidentally restored by a > cherry-pick into drm-next and now has percolated back to > drm-intel-next-queued. > > Fixes: 2e46a2a0b014

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Suppress some random warnings

== Series Details == Series: drm/i915/gem: Suppress some random warnings URL : https://patchwork.freedesktop.org/series/77431/ State : success == Summary == CI Bug Log - changes from CI_DRM_8506_full -> Patchwork_17715_full Summary ---

Re: [Intel-gfx] [PATCH] dma-fence: add might_sleep annotation to _wait()

On Wed, May 20, 2020 at 08:54:36AM +0200, Christian König wrote: > Am 19.05.20 um 15:27 schrieb Daniel Vetter: > > Do it uncontionally, there's a separate peek function with > > dma_fence_is_signalled() which can be called from atomic context. > > > > v2: Consensus calls for an unconditional

[Intel-gfx] [PATCH] drm: Replace deprecated function in drm_crtc_helper

Replace deprecated function drm_modeset_lock/unlock_all with helper function DRM_MODESET_LOCK_ALL_BEGIN/END. Signed-off-by: Sidong Yang --- drivers/gpu/drm/drm_crtc_helper.c | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git

<    1   2