== Series Details ==
Series: dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
URL : https://patchwork.freedesktop.org/series/79980/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8804 -> Patchwork_18248
Unlike rcs where we have conclusive evidence from our selftesting that
disabling the preparser before performing the TLB invalidate and
relocations does impact upon the GPU execution, the evidence for the
same requirement on xcs is much more circumstantial. Let's apply the
preparser disable
The flags passed to the wait_entry.func are passed onwards to
try_to_wake_up(), which has a very particular interpretation for its
wake_flags. In particular, beyond the published WF_SYNC, it has a few
internal flags as well. Since we passed the fence->error down the chain
via the flags argument,
Since we want to read the values from the HWSP as written to by the GPU,
warn the compiler that the values are volatile.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 23 +++--
1 file changed, 12
I915_GEM_THROTTLE dates back to the time before contexts where there was
just a single engine, and therefore a single timeline and request list
globally. That request list was in execution/retirement order, and so
walking it to find a particular aged request made sense and could be
split per file.
Hi,
I opened a bug ( https://gitlab.freedesktop.org/drm/intel/-/issues/1378 )
a few months back, but no one seems to have looked at it. I'm
emailing here to hopefully get a suggestion on a path forward.
tl;dr: when resuming from DPMS, link training channel equalization
fails on the Dell 7200
== Series Details ==
Series: dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
URL : https://patchwork.freedesktop.org/series/79980/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dca1dc9ea07c dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
-:66:
Quoting Thomas Hellström (Intel) (2020-07-27 10:24:24)
> Hi, Chris,
>
> It appears to me like this series is doing a lot of different things:
>
> - Various optimizations
> - Locking rework
> - Adding schedulers
> - Other misc fixes
>
> Could you please separate out as much as possible the
Quoting Thomas Hellström (Intel) (2020-07-23 17:09:15)
>
> On 2020-07-15 13:50, Chris Wilson wrote:
> > Our timeline lock is our defence against a concurrent execbuf
> > interrupting our request construction. we need hold it throughout or,
> > for example, a second thread may interject a
Since we use the module parameters stored inside the drm_i915_device
itself, we need to ensure the mock i915_device also sets up the right
defaults.
Fixes: 8a25c4be583d ("drm/i915/params: switch to device specific parameters")
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Reviewed-by: Tvrtko
Quoting Tvrtko Ursulin (2020-07-17 14:23:22)
>
> On 15/07/2020 12:50, Chris Wilson wrote:
> > Before we can execute a request, we must wait for all of its vma to be
> > bound. This is a frequent operation for which we can optimise away a
> > few atomic operations (notably a cmpxchg) in lieu of
On 7/15/20 1:50 PM, Chris Wilson wrote:
Remove the stub i915_vma_pin() used for incrementally pining objects for
s/pining/pinning/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 7/23/20 6:09 PM, Thomas Hellström (Intel) wrote:
On 2020-07-15 13:50, Chris Wilson wrote:
Our timeline lock is our defence against a concurrent execbuf
interrupting our request construction. we need hold it throughout or,
for example, a second thread may interject a relocation request in
Quoting Thomas Hellström (Intel) (2020-07-28 10:46:51)
>
> On 7/15/20 1:50 PM, Chris Wilson wrote:
> > Remove the stub i915_vma_pin() used for incrementally pining objects for
>
> s/pining/pinning/
Pining for the fjords.
-Chris
___
Intel-gfx mailing
Quoting Tvrtko Ursulin (2020-07-17 15:36:04)
>
> On 15/07/2020 12:50, Chris Wilson wrote:
> > Remove the stub i915_vma_pin() used for incrementally pining objects for
> > execbuf (under the severe restriction that they must not wait on a
> > resource as we may have already pinned it) and replace
On 7/16/20 5:53 PM, Tvrtko Ursulin wrote:
On 15/07/2020 16:43, Maarten Lankhorst wrote:
Op 15-07-2020 om 13:51 schreef Chris Wilson:
Our goal is to pull all memory reservations (next iteration
obj->ops->get_pages()) under a ww_mutex, and to align those
reservations
with other drivers, i.e.
Quoting Tvrtko Ursulin (2020-07-17 13:38:01)
>
> On 15/07/2020 12:50, Chris Wilson wrote:
> > + /* Even if we have not used the cache, we may still have a barrier */
> > + if (!ref->cache)
> > + ref->cache = fetch_node(ref->tree.rb_node);
> > +
> > + /* Keep the MRU cached
Quoting Thomas Hellström (Intel) (2020-07-27 19:08:39)
>
> On 7/15/20 1:51 PM, Chris Wilson wrote:
> > Acquire all the objects and their backing storage, and page directories,
> > as used by execbuf under a single common ww_mutex. Albeit we have to
> > restart the critical section a few times in
Quoting Tvrtko Ursulin (2020-07-17 14:04:58)
>
> On 15/07/2020 12:50, Chris Wilson wrote:
> > Rather than require the next timeline after idling to match the MRU
> > before idling, reset the index on the node and allow it to match the
> > first request. However, this requires cmpxchg(u64) and so
== Series Details ==
Series: drm/i915: Copy default modparams to mock i915_device (rev4)
URL : https://patchwork.freedesktop.org/series/79736/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
GPU drivers need this in their shrinkers, to be able to throw out
mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers,
but that loop is resolved by trylocking in shrinkers.
So full hierarchy is now (ignore some of the other branches we already
have primed):
mmap_read_lock ->
Quoting Thomas Hellström (Intel) (2020-07-23 15:33:20)
>
> On 2020-07-15 13:50, Chris Wilson wrote:
> > We need to make the DMA allocations used for page directories to be
> > performed up front so that we can include those allocations in our
> > memory reservation pass. The downside is that we
Move the __intel_breadcrumbs_arm_irq earlier, next to the disarm_irq, so
that we can make use of it in the following patch.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 84 ++---
1 file changed, 42 insertions(+), 42
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 30 +++
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/gpu/drm/i915/i915_request.h
Since the breadcrumb enabling/cancelling itself is serialised by the
breadcrumbs.irq_lock, with a bit of care we can remove the outer
serialisation with i915_request.lock for concurrent
dma_fence_enable_signaling(). This has the important side-effect of
eliminating the nested i915_request.lock
Since we use a flag within i915_request.flags to indicate when we have
boosted the request (so that we only apply the boost) once, this can be
used as the serialisation with i915_request_retire() to avoid having to
explicitly take the i915_request.lock which is more heavily contended.
It's been a while since gen6_rps_boost() [that only worked on gen6+] was
replaced by intel_rps_boost() that understood itself when rps was
active. Since the intel_rps_boost() is gen-agnostic, just call it.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be
Originally, we used the signal->lock as a means of following the
previous link in its timeline and peeking at the previous fence.
However, we have replaced the explicit serialisation with a series of
very careful probes that anticipate the links being deleted and the
fences recycled before we are
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client
On Mon, Jul 27, 2020 at 03:51:06PM -0500, Daniel Dadap wrote:
> Changes to allow vga-switcheroo to switch the mux while modesetting
> clients remain active. There is existing support for switching the
> mux without checking can_switch; however, this support also does not
> reprobe after the mux
Hi Dave and Daniel,
here's this week's PR for drm-misc-fixes. It's mostly driver stuff.
There's one fix in the GEM ioctl code, but it has no impact on the
UAPI.
Best regards
Thomas
drm-misc-fixes-2020-07-28:
* drm: fix possible use-after-free
* dbi: fix SPI Type 1 transfer
* drm_fb_helper:
Quoting Thomas Hellström (Intel) (2020-07-22 12:19:28)
>
> On 2020-07-15 13:50, Chris Wilson wrote:
> > Rather than require the next timeline after idling to match the MRU
> > before idling, reset the index on the node and allow it to match the
> > first request. However, this requires
Quoting Thomas Hellström (Intel) (2020-07-27 19:19:19)
>
> On 7/15/20 1:51 PM, Chris Wilson wrote:
> > 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
It's been a while since gen6_rps_boost() [that only worked on gen6+] was
replaced by intel_rps_boost() that understood itself when rps was
active. Since the intel_rps_boost() is gen-agnostic, just call it.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Reduce ctx->engine_mutex for
reading the clone source
URL : https://patchwork.freedesktop.org/series/79991/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8807 -> Patchwork_18256
== Series Details ==
Series: series starting with [1/7] drm/i915: Add a couple of missing
i915_active_fini()
URL : https://patchwork.freedesktop.org/series/79992/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be
== Series Details ==
Series: series starting with [1/3] drm/i915: Preallocate stashes for vma
page-directories
URL : https://patchwork.freedesktop.org/series/79994/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8807 -> Patchwork_18258
== Series Details ==
Series: drm/i915: Copy default modparams to mock i915_device (rev4)
URL : https://patchwork.freedesktop.org/series/79736/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8804_full -> Patchwork_18249_full
On Fri, Jul 24, 2020 at 02:39:00PM -0700, Lucas De Marchi wrote:
> From: Venkata Sandeep Dhanalakota
>
> On dgfx register range has been extended to go up to 4MB.
>
> Cc: Daniele Ceraolo Spurio
> Cc: Michael J. Ruhl
> Signed-off-by: Venkata Sandeep Dhanalakota
> Signed-off-by: Lucas De
== Series Details ==
Series: drm/i915/gem: Remove disordered per-file request list for throttling
(rev5)
URL : https://patchwork.freedesktop.org/series/79600/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8805_full -> Patchwork_18250_full
== Series Details ==
Series: dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
URL : https://patchwork.freedesktop.org/series/79980/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8804_full -> Patchwork_18248_full
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Disable preparser around xcs
invalidations on tgl
URL : https://patchwork.freedesktop.org/series/79985/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8805_full -> Patchwork_18251_full
== Series Details ==
Series: drm/i915: Copy default modparams to mock i915_device (rev4)
URL : https://patchwork.freedesktop.org/series/79736/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8804 -> Patchwork_18249
Summary
Before we peek at the barrier status for an assert, first serialise with
its callbacks so that we see a stable value.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_context.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
== Series Details ==
Series: drm/i915/gem: Remove disordered per-file request list for throttling
(rev5)
URL : https://patchwork.freedesktop.org/series/79600/
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: drm/i915: Filter wake_flags passed to default_wake_function (rev2)
URL : https://patchwork.freedesktop.org/series/79824/
State : failure
== Summary ==
Applying: drm/i915: Filter wake_flags passed to default_wake_function
Using index info to reconstruct a base
== Series Details ==
Series: drm/i915/selftests: Flush the active barriers before asserting
URL : https://patchwork.freedesktop.org/series/79995/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8807 -> Patchwork_18259
== Series Details ==
Series: series starting with [1/7] drm/i915: Add a couple of missing
i915_active_fini()
URL : https://patchwork.freedesktop.org/series/79992/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8807 -> Patchwork_18257
On Fri, Jul 24, 2020 at 02:38:59PM -0700, Lucas De Marchi wrote:
> From: Uma Shankar
>
> Most of TGL power wells are re-used for DG1. However, AUDIO Power
> Domain is moved from PG3 to PG0. Handle the change and initialize
> power wells with the new power well structure.
>
> Some of the Audio
== Series Details ==
Series: drm/i915/selftests: Flush the active barriers before asserting
URL : https://patchwork.freedesktop.org/series/79995/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/gt: Delay taking the spinlock for grabbing from the buffer
pool (rev5)
URL : https://patchwork.freedesktop.org/series/79855/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be
On Fri, Jul 24, 2020 at 02:39:02PM -0700, Lucas De Marchi wrote:
> From: Aditya Swarup
>
> DG1 has 4 DPLLs where DPLL0 and DPLL1 drive DDIA/B and
> DPLL2 and DPLL3 drive DDIC/DDID.
Since this is a DG1-specific commit with DG1-specific macros, we should
also use the DG1-specific terminology in
== Series Details ==
Series: drm/i915/gt: Delay taking the spinlock for grabbing from the buffer
pool (rev5)
URL : https://patchwork.freedesktop.org/series/79855/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8807 -> Patchwork_18260
On Fri, Jul 24, 2020 at 02:39:03PM -0700, Lucas De Marchi wrote:
> 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
== Series Details ==
Series: series starting with [1/3] drm/i915: Preallocate stashes for vma
page-directories
URL : https://patchwork.freedesktop.org/series/79994/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be
== Series Details ==
Series: series starting with [1/7] drm/i915: Add a couple of missing
i915_active_fini()
URL : https://patchwork.freedesktop.org/series/79992/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8807_full -> Patchwork_18257_full
== Series Details ==
Series: series starting with [1/3] drm/i915: Preallocate stashes for vma
page-directories
URL : https://patchwork.freedesktop.org/series/79994/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8807_full -> Patchwork_18258_full
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Serialise debugfs
i915_gem_objects with ctx->mutex
URL : https://patchwork.freedesktop.org/series/79990/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8807_full -> Patchwork_18255_full
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Reduce ctx->engine_mutex for
reading the clone source
URL : https://patchwork.freedesktop.org/series/79991/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8807_full -> Patchwork_18256_full
== Series Details ==
Series: drm/i915: Remove gen check before calling intel_rps_boost (rev2)
URL : https://patchwork.freedesktop.org/series/79791/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8807_full -> Patchwork_18253_full
== Series Details ==
Series: series starting with [01/12] drm/i915: Remove gen check before calling
intel_rps_boost
URL : https://patchwork.freedesktop.org/series/79988/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8807_full -> Patchwork_18254_full
When cloning the engines from the source context, we need to ensure that
the engines are not freed as we copy them, and that the flags we clone
from the source correspond with the engines we copy across. To do this
we need only take a reference to the src->engines, rather than hold the
Some very low hanging fruit, but contention on the pool->lock is
noticeable between intel_gt_get_buffer_pool() and pool_retire(), with
the majority of the hold time due to the locked list iteration. If we
make the node itself RCU protected, we can perform the search for an
suitable node just under
Quoting Daniel Vetter (2020-07-27 20:32:45)
> On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson wrote:
> >
> > An unfortunate sequence of events, but it turns out there is a valid
> > usecase for being able to free/decouple the driver objects before they
> > are freed by the DRM core. In particular,
On Tue, 28 Jul 2020 at 16:59, Chris Wilson wrote:
>
> Some very low hanging fruit, but contention on the pool->lock is
> noticeable between intel_gt_get_buffer_pool() and pool_retire(), with
> the majority of the hold time due to the locked list iteration. If we
> make the node itself RCU
== Series Details ==
Series: drm/i915: Remove gen check before calling intel_rps_boost (rev2)
URL : https://patchwork.freedesktop.org/series/79791/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
> Before this commit a suspend + resume of the LPSS PWM controller
> would result in the controller being reset to its defaults of
> output-freq = clock/256, duty-cycle=100%, until someone changes
> to the output-freq and/or duty-cycle
Hi,
On 7/28/20 9:36 PM, Andy Shevchenko wrote:
On Fri, Jul 17, 2020 at 03:37:44PM +0200, Hans de Goede wrote:
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with
Take a snapshot of the ctx->engines, so we can avoid taking the
ctx->engines_mutex for a mere read in get_engines().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 39 +
1 file changed, 8 insertions(+), 31 deletions(-)
diff --git
When cloning the engines from the source context, we need to ensure that
the engines are not freed as we copy them, and that the flags we clone
from the source correspond with the engines we copy across. To do this
we need only take a reference to the src->engines, rather than hold the
Since the debugfs may peek into the GEM contexts as the corresponding
client/fd is being closed, we may try and follow a dangling pointer.
However, the context closure itself is serialised with the ctx->mutex,
so if we hold that mutex as we inspect the state coupled in the context,
we know the
If no active callback is defined for i915_active, we do not need to
serialise its enabling with the mutex. We still do only want to call the
debug activate once, and must still serialise with a concurrent retire.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Thomas
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.
v2:
Before we can execute a request, we must wait for all of its vma to be
bound. This is a frequent operation for which we can optimise away a
few atomic operations (notably a cmpxchg) in lieu of the RCU protection.
Signed-off-by: Chris Wilson
Reviewed-by: Thomas Hellström
---
We use i915_active_fini() as a debug check on the i915_active state
before freeing. If we forget to call it, we may end up angering the
debugobjects contained within.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Thomas Hellström
---
Rather than require the next timeline after idling to match the MRU
before idling, reset the index on the node and allow it to match the
first request. However, this requires cmpxchg(u64) and so is not trivial
on 32b, so for compatibility we just fallback to keeping the cached node
pointing to the
Whenever an i915_active idles, we prune its tree of old fence slots to
prevent a gradual leak should it be used to track many, many timelines.
The downside is that we then have to frequently reallocate the rbtree.
A compromise is that we keep the most recently used fence slot, and
reuse that for
As the conversion between idle-barrier and full i915_active_fence is
already serialised by explicit memory barriers, we can reduce the
spinlock in i915_active_acquire_preallocate_barrier() for finding an
idle-barrier to reuse to an RCU read lock to ensure the fence remains
valid, only taking the
Some very low hanging fruit, but contention on the pool->lock is
noticeable between intel_gt_get_buffer_pool() and pool_retire(), with
the majority of the hold time due to the locked list iteration. If we
make the node itself RCU protected, we can perform the search for an
suitable node just under
On Fri, Jul 17, 2020 at 03:37:42PM +0200, Hans de Goede wrote:
> In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
> runtime-pm reference; and then on any errors it needs to release it
> again.
>
> This leads to somewhat hard to read code. This commit introduces a new
>
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Serialise debugfs
i915_gem_objects with ctx->mutex
URL : https://patchwork.freedesktop.org/series/79990/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit
On Fri, Jul 17, 2020 at 03:37:44PM +0200, Hans de Goede wrote:
> While looking into adding atomic-pwm support to the pwm-crc driver I
> noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
> there is a clock-divider which divides this with a value between 1-128,
> and there are 256
Hi,
On 7/28/20 8:45 PM, Andy Shevchenko wrote:
On Fri, Jul 17, 2020 at 03:37:42PM +0200, Hans de Goede wrote:
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code.
We need to make the DMA allocations used for page directories to be
performed up front so that we can include those allocations in our
memory reservation pass. The downside is that we have to assume the
worst case, even before we know the final layout, and always allocate
enough page directories
kmalloc uses power-of-two slab buckets for small allocations (up to a
few pages). Since i915_page_directory is a page of pointers, plus a
couple more, this is rounded up to 8K, and we waste nearly 50% of that
allocation. Long terms this leads to poor memory utilisation, bloating
the kernel
The GEM object is grossly overweight for the practicality of tracking
large numbers of individual pages, yet it is currently our only
abstraction for tracking DMA allocations. Since those allocations need
to be reserved upfront before an operation, and that we need to break
away from simple system
== Series Details ==
Series: series starting with [01/12] drm/i915: Remove gen check before calling
intel_rps_boost
URL : https://patchwork.freedesktop.org/series/79988/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8807 -> Patchwork_18254
Some very low hanging fruit, but contention on the pool->lock is
noticeable between intel_gt_get_buffer_pool() and pool_retire(), with
the majority of the hold time due to the locked list iteration. If we
make the node itself RCU protected, we can perform the search for an
suitable node just under
Hi,
On 7/28/20 8:57 PM, Andy Shevchenko wrote:
On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone
On 28/07/2020 16:31, Chris Wilson wrote:
kmalloc uses power-of-two slab buckets for small allocations (up to a
few pages). Since i915_page_directory is a page of pointers, plus a
couple more, this is rounded up to 8K, and we waste nearly 50% of that
allocation. Long terms this leads to poor
On Fri, 2020-07-24 at 14:38 -0700, Lucas De Marchi wrote:
> From: Matt Roper <
> matthew.d.ro...@intel.com
> >
>
> DG1 always uses a 38.4 MHz rawclk rather than the 19.2/24 MHz
> frequencies on CNP+. Note that register bits associated with this
> frequency confusingly use 37 for the divider
== Series Details ==
Series: drm/i915: Remove gen check before calling intel_rps_boost (rev2)
URL : https://patchwork.freedesktop.org/series/79791/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8807 -> Patchwork_18253
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Reduce ctx->engine_mutex for
reading the clone source
URL : https://patchwork.freedesktop.org/series/79991/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each
On the virtual engines, we only use the intel_breadcrumbs for tracking
signaling of stale breadcrumbs from the irq_workers. They do not have
any associated interrupt handling, active requests are passed to a
physical engine and associated breadcrumb interrupt handler. This causes
issues for us as
After staring at the breadcrumb enabling/cancellation and coming to the
conclusion that the cause of the mysterious stale breadcrumbs must the
act of submitting a completed requests, we can then redirect those
completed requests onto a dedicated signaled_list at the time of
construction and so
== Series Details ==
Series: drm/i915/gem: Remove disordered per-file request list for throttling
(rev5)
URL : https://patchwork.freedesktop.org/series/79600/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8805 -> Patchwork_18250
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Disable preparser around xcs
invalidations on tgl
URL : https://patchwork.freedesktop.org/series/79985/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8805 -> Patchwork_18251
== Series Details ==
Series: series starting with [01/12] drm/i915: Remove gen check before calling
intel_rps_boost
URL : https://patchwork.freedesktop.org/series/79988/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e55a35c962bb drm/i915: Remove gen check before calling
== Series Details ==
Series: series starting with [01/12] drm/i915: Remove gen check before calling
intel_rps_boost
URL : https://patchwork.freedesktop.org/series/79988/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't
1 - 100 of 110 matches
Mail list logo
