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_context
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
== 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
--
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 con
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 que
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
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: Chris
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 t
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 4696
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: https://gitlab.freed
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
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
Signe
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 +++---
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
---
drivers/gpu/d
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 4
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 preempt-to-b
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
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
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 f
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 virtua
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
__igt_breadcrumbs_smoketest
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 a
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 depend
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.
Signed-
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 +--
drivers/gpu/drm/i915/gem/i915_gem_shm
== 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 tree..
== 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
---
**SUCCES
== 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 prefe
== 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
---
== 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
---
**F
== 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: CHECK:COMPARI
== 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 separ
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 calcu
== 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
===
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:
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 w
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@lists.freedeskto
== 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
---
**SUCCES
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 sh
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 cha
== 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
===
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 ("drm/i91
== 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
---
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 might
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 a/drivers/gpu/drm/drm_crtc_helper.c
== Series Details ==
Series: drm/i915/ehl: Wa_22010271021 (rev2)
URL : https://patchwork.freedesktop.org/series/77428/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8506_full -> Patchwork_17716_full
Summary
---
**FAI
On 20/05/2020 11:38, Chris Wilson wrote:
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
Quoting Tvrtko Ursulin (2020-05-20 12:54:19)
>
> On 20/05/2020 11:38, Chris Wilson wrote:
> > @@ -1083,10 +1154,10 @@ print_header(struct engines *engines, double t,
> > printf("\033[H\033[J");
> >
> > if (lines++ < con_h)
> > - printf("intel-gpu-
Quoting Chris Wilson (2020-05-20 13:01:35)
> Quoting Tvrtko Ursulin (2020-05-20 12:54:19)
> >
> > On 20/05/2020 11:38, Chris Wilson wrote:
> > > @@ -1083,10 +1154,10 @@ print_header(struct engines *engines, double t,
> > > printf("\033[H\033[J");
> > >
> > > if (line
== Series Details ==
Series: drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC (rev2)
URL : https://patchwork.freedesktop.org/series/77382/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8506_full -> Patchwork_17717_full
Summa
Hi Dave & Daniel,
On top of the drm-intel-next PR one fix for TypeC mode resets and
two compile time warning fixes.
CI results for your viewing:
https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/combined-alt.html
CI_DINF_189 = drm-intel-next pull
CI_DINF_190 = this pull (3 patches)
There i
== Series Details ==
Series: drm/i915/gt: Trace the CS interrupt (rev4)
URL : https://patchwork.freedesktop.org/series/77441/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8511 -> Patchwork_17727
Summary
---
**FAILUR
== 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 : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6190d8ce3829 drm/i915/params: don't expose inject_pr
== 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 : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commi
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
This conflicts with the ww mutex handling, which needs to drop
the references after gpu submission anyway, because otherwise we
may risk unlocking a BO after first freeing it.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: M
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 inserti
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insert
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get call
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Ensure that execbuf selftests keep passing by using ww handling.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../i915/gem/se
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 9d306dc9849d..a8f1d438affd 100644
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten La
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
Signed-off-by: Maarten Lankhorst
---
drivers/g
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3
The lock here should be interruptible, so we can backoff if needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i91
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+),
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This fin
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 9 -
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rend
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.
[mlankhorst: Adjusted for reloc_gpu_flush() changes]
Cc: Chris Wilson
Cc: Matthew
== 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 -> Patchwork_17728
===
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 setups. So add an additional wait when R0' is
mismatched.
Signed-off-by: Sean Paul
Changes in v2:
- Actually add the delay in R0`
On Mon, May 18, 2020 at 12:41 PM Ramalingam C wrote:
>
> On 2020-05-18 at 10:32:09 -0400, Sean Paul wrote:
> > On Fri, May 15, 2020 at 10:48 AM Ramalingam C
> > wrote:
> > >
> > > On 2020-04-29 at 15:54:46 -0400, Sean Paul wrote:
> > > > From: Sean Paul
> > > >
> > > > Changes in v6:
> > > > -R
== Series Details ==
Series: drm/i915/hdcp: Add additional R0' wait
URL : https://patchwork.freedesktop.org/series/77439/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8506_full -> Patchwork_17719_full
Summary
---
**
Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
function which also includes pinning and map in cpu domain.
No functional change is dsb write/commit functions.
Now dsb get/put function is removed and ref-count mechanism is
not needed. Below dsb api added to do respective job
== 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 -> Patchwork_17729
Summary
---
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath".
URL : https://patchwork.freedesktop.org/series/77472/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e8a9ca7ebbde Revert "drm/i915/gem: Drop relocation slowpath".
-:80: WA
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath".
URL : https://patchwork.freedesktop.org/series/77472/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath".
URL : https://patchwork.freedesktop.org/series/77472/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8511 -> Patchwork_17730
=
== 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 -> Patchwork_17731
Summary
---
**SUC
== 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 -> Patchwork_17732
Summ
Checking with hweight8 if plane configuration had
changed seems to be wrong as different plane configs
can result in a same hamming weight.
So lets check the bitmask itself.
v2: Fixed "from" field which got corrupted for some weird reason
Reviewed-by: Manasi Navare
Signed-off-by: Stanislav Lisov
So lets support it.
v2: - Fixed "from" field which got corrupted for some weird reason
Reviewed-by: Manasi Navare
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display
According to BSpec max BW per slice is calculated using formula
Max BW = CDCLK * 64. Currently when calculating min CDCLK we
account only per plane requirements, however in order to avoid
FIFO underruns we need to estimate accumulated BW consumed by
all planes(ddb entries basically) residing on tha
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev18)
URL : https://patchwork.freedesktop.org/series/74739/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
27d0a2a78122 drm/i915: Decouple cdclk calculation from modeset checks
b0928a963b24 drm/i915: E
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev18)
URL : https://patchwork.freedesktop.org/series/74739/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
+drivers/
On Tue, 2020-05-19 at 13:12 -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)
>
> Signed-off-by: Swathi Dhanavanthri
> ---
> drivers/gpu/drm/i91
== 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 -> Patchwork_17733
Summary
---
Check that if we submit a request that is held up by an external fence,
that we conserve power during the wait as the GPU is idle.
Signed-off-by: Chris Wilson
Cc: Venkata Sandeep Dhanalakota
---
tests/i915/i915_pm_rc6_residency.c | 82 ++
1 file changed, 82 insertion
Use a spinner to create a fence, and then use that as to synchronise
another batch to cancel the spinner.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_schedule.c | 121 +++--
1 file changed, 116 insertions(+), 5 deletions(-)
diff --git a/te
On Wed, May 20, 2020 at 11:30:25AM +0200, Borislav Petkov wrote:
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
On Mon, May 11, 2020 at 06:12:32PM +, Ruhl, Michael J wrote:
> >-Original Message-
> >From: dri-devel On Behalf Of
> >Daniel Vetter
> >Sent: Monday, May 11, 2020 5:12 AM
> >To: LKML
> >Cc: David Airlie ; Daniel Vetter ;
> >Intel Graphics Development ; DRI
> >Development ; Thomas Zimme
On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote:
> On Tue, May 12, 2020 at 9:12 AM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote:
> > >
> > > On Mon, 11 May 2020 at 19:37, Oded Gabbay wrote:
> > > >
> > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vett
1 - 100 of 168 matches
Mail list logo
