Re: [Intel-gfx] [PATCH v5 2/5] drm/i915: Add support for async flips in I915
On 7/25/2020 4:56 AM, Paulo Zanoni wrote:
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
v2: -Move the Async flip enablement to individual patch (Paulo)
v3: -Rebased.
v4: -Add separate plane hook for async flip case (Ville)
v5: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +
drivers/gpu/drm/i915/display/intel_sprite.c | 25
drivers/gpu/drm/i915/i915_reg.h | 1 +
3 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b8ff032195d9..4773f39e5924 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4766,6 +4766,12 @@ u32 skl_plane_ctl(const struct intel_crtc_state
*crtc_state,
const struct drm_intel_sprite_colorkey *key = &plane_state->ckey;
u32 plane_ctl;
+ /* During Async flip, no other updates are allowed */
My understanding is that this function is fully setting the right bits
based on the chosen config (instead of doing read-modify-write), and
the checks for "other updates" were done before. So the logic
implemented here of early returning doesn't make sense.
Thanks for the review.
Yes the check for other updates are done before.
So I could either do read-modify-write and return early, or,
keep the existing code flow as is, since the are checks already present.
I will keep the existing flow and remove the early return in the next
revision.
+ if (crtc_state->uapi.async_flip) {
+ plane_ctl |= PLANE_CTL_ASYNC_FLIP;
I wonder why gcc does not complain we're ORing with an unitialized
value.
Will initialize the plane_ctl variable to zero.
+ return plane_ctl;
+ }
+
plane_ctl = PLANE_CTL_ENABLE;
It seems to be the return above means we'll never even try to enable
the plane, we're only relying on the fact that plane_ctl is not zero
initialize so maybe bit 31 is already set.
Since we only allow async flips on planes that are already enabled,
I assumed this would not be needed. Also, other than bit 9 (async
address update enable), this register is double buffered and cannot be
updated asynchronously.
if (INTEL_GEN(dev_priv) < 10 && !IS_GEMINILAKE(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index c26ca029fc0a..3747482e8fa3 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -603,6 +603,24 @@ icl_program_input_csc(struct intel_plane *plane,
PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
}
+static void
+skl_program_async_surface_address(struct drm_i915_private *dev_priv,
+ const struct intel_plane_state *plane_state,
+ enum pipe pipe, enum plane_id plane_id,
+ u32 surf_addr)
+{
+ unsigned long irqflags;
+ u32 plane_ctl = plane_state->ctl;
+
+ spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+
+ intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
+ intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
+ intel_plane_ggtt_offset(plane_state) + surf_addr);
+
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+}
+
static void
skl_program_plane(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
@@ -631,6 +649,13 @@ skl_program_plane(struct intel_plane *plane,
u32 keymsk, keymax;
u32 plane_ctl = plane_state->ctl;
+ /* During Async flip, no other updates are allowed */
+ if (crtc_state->uapi.async_flip) {
+ skl_program_async_surface_address(dev_priv, plane_state,
+ pipe, plane_id, surf_addr);
+ return;
+ }
I'd vote for us to keep the "don't rewrite registers that shouldn't
change" part on its own commit, since it's just an optimization. It
could even go at the end of the series. But perhaps this is simple
enough and not needed.
Will move this change to the end of the series.
Thanks,
Karthik.B.S
+
plane_ctl |= skl_plane_ctl_crtc(crtc_state);
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8cee06314d5d..19aad4199874 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6935,6 +6935,7 @@ enum {
#define PLANE_CTL_TILED_X (1 << 10)
#define PLANE_CTL_TILED_Y (4 << 10)
#define PLANE_CTL_TILED_YF (5 << 10)
+#define PLANE_CTL_ASYNC_FLIP (1
Re: [Intel-gfx] [v2] drm/i915/display/fbc: Disable fbc by default on TGL
> -Original Message- > From: Ville Syrjälä > Sent: Thursday, July 16, 2020 8:15 PM > To: Shankar, Uma > Cc: intel-gfx@lists.freedesktop.org; Lisovskiy, Stanislav > > Subject: Re: [v2] drm/i915/display/fbc: Disable fbc by default on TGL > > On Thu, Jul 16, 2020 at 08:28:57PM +0530, Uma Shankar wrote: > > Fbc is causing random underruns in CI execution on TGL platforms. > > Disabling the same while the problem is being debugged and analyzed. > > > > v2: Moved the check below the module param check (Ville) > > > > Cc: Stanislav Lisovskiy > > Cc: Ville Syrjälä > > Signed-off-by: Uma Shankar > > Acked-by: Ville Syrjälä This is pushed to dinq. Thanks for the review. Regards, Uma Shankar > > --- > > drivers/gpu/drm/i915/display/intel_fbc.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c > b/drivers/gpu/drm/i915/display/intel_fbc.c > > index 3a4f980788a6..195b8be4532a 100644 > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c > > @@ -1426,6 +1426,13 @@ static int intel_sanitize_fbc_option(struct > drm_i915_private *dev_priv) > > if (!HAS_FBC(dev_priv)) > > return 0; > > > > + /* > > +* Fbc is causing random underruns in CI execution on TGL platforms. > > +* Disabling the same while the problem is being debugged and analyzed. > > +*/ > > + if (IS_TIGERLAKE(dev_priv)) > > + return 0; > > + > > if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9) > > return 1; > > > > -- > > 2.22.0 > > -- > Ville Syrjälä > Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Stall around xcs invalidations on tgl
Quoting Mika Kuoppala (2020-07-24 12:59:04)
> Chris Wilson writes:
>
> > Whether this is an arbitrary stall or a vital ingredient, neverthess the
> > impact is noticeable. If we do not have the stall around the xcs
> > invalidation before a request, writes within that request sometimes go
> > astray.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2169
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 18 --
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 353b1717fe84..104bef04498d 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -4761,10 +4761,12 @@ static int gen12_emit_flush_render(struct
> > i915_request *request,
> >
> > static int gen12_emit_flush(struct i915_request *request, u32 mode)
> > {
> > +#define WA_CNT 32 /* Magic delay */
>
> Utterly nasty. We need to hunt for an explanation.
Utterly. The cost is about 20us per request. I'm going to see if I can
find an alternative.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] vga-switcheroo: initial dynamic mux switch support
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 switch is complete. This patch series adds a new > type of switch event which switches immediately while still calling > client driver callbacks, and updates the i915 DRM-KMS driver to reprobe > eDP outputs after switching the mux to an i915-driven GPU, and to avoid > using eDP links (which i915 always assumes to be connected) while the > mux is switched away. So before digging into the details I think the big issue we need to solve first is locking. And current vga-switcheroo is already broken in that regard (there's some fixme comments in drivers about it), but I never cared because it was full device switch only, initiated by users. But you now add vgaswitcheroo to modeset code, and runtime switching, I don't think we can ignore locking here anymore. Also, it's classic abba deadlock design: i915 modeset code calls your new functions in vgaswitcheroo, and vgaswitcheroo calls into modeset code to shut down stuff. This doesn't work (you get away with it by omitting locking in some places, like the current code). One totally nuts idea I've had is to protect vgaswitcheroo output state with a drm_modeset_lock. That supports full graph locking, which means it doesn't matter where we start: nouveau, i915, vgaswitcheroo. So could work out neatly. Problem: That still leaves the loop for the device switching, which is all tangled up here, so either we make this completely separate, or we figure out a plan how make this work for device switching too. And the additional problem is that drm_modeset_lock is already a highly entrenched lock, I'm not sure whether we can also support the device switching with that approach: The device locking we'd need would need to be an outermost lock, or at least fairly big, whereas drm_modeset_lock is kinda a level below. Or I'm making a mess here (it is already one after all). Also, where's the other side? I know the other side you care about is in the nvidia blob driver, but that doesn't count for upstream. We need that code in nouveau for review and merging. Cheers, Daniel > > Daniel Dadap (6): > vga-switcheroo: add new "immediate" switch event type > vga-switcheroo: Add a way to test for the active client > vga-switcheroo: notify clients of pending/completed switch events > i915: implement vga-switcheroo reprobe() callback > i915: fail atomic commit when muxed away > i915: bail out of eDP link training while mux-switched away > > drivers/gpu/drm/i915/display/intel_display.c | 7 + > .../drm/i915/display/intel_dp_link_training.c | 9 ++ > drivers/gpu/drm/i915/i915_switcheroo.c| 27 +++- > drivers/gpu/vga/vga_switcheroo.c | 153 ++ > include/linux/vga_switcheroo.h| 20 +++ > 5 files changed, 185 insertions(+), 31 deletions(-) > > -- > 2.18.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/66] drm/i915/gem: Remove the call for no-evict i915_vma_pin
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
[Intel-gfx] [PULL] drm-misc-fixes
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: use memcpy_io on bochs' sparc64 * mcde: fix stability * panel: fix display noise on auo,kd101n80-45na * panel: delay HPD checks for boe_nv133fhm_n61 * bridge: drop connector check in nwl-dsi bridge * bridge: set proper bridge type for adv7511 * of: fix a double free The following changes since commit f3f90c6db188d437add55aaffadd5ad5bcb8cda6: drm/lima: fix wait pp reset timeout (2020-07-20 08:46:06 +0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-07-28 for you to fetch changes up to 8490d6a7e0a0a6fab5c2d82d57a3937306660864: drm: hold gem reference until object is no longer accessed (2020-07-27 22:05:51 +0200) * drm: fix possible use-after-free * dbi: fix SPI Type 1 transfer * drm_fb_helper: use memcpy_io on bochs' sparc64 * mcde: fix stability * panel: fix display noise on auo,kd101n80-45na * panel: delay HPD checks for boe_nv133fhm_n61 * bridge: drop connector check in nwl-dsi bridge * bridge: set proper bridge type for adv7511 * of: fix a double free Biju Das (1): drm: of: Fix double-free bug Douglas Anderson (1): drm: panel: simple: Delay HPD checking on boe_nv133fhm_n61 for 15 ms Guido Günther (1): drm/bridge: nwl-dsi: Drop DRM_BRIDGE_ATTACH_NO_CONNECTOR check. Jitao Shi (1): drm/panel: Fix auo, kd101n80-45na horizontal noise on edges of panel Laurentiu Palcu (1): drm/bridge/adv7511: set the bridge type properly Linus Walleij (1): drm/mcde: Fix stability issue Paul Cercueil (1): drm/dbi: Fix SPI Type 1 (9-bit) transfer Sam Ravnborg (1): drm/drm_fb_helper: fix fbdev with sparc64 Steve Cohen (1): drm: hold gem reference until object is no longer accessed drivers/gpu/drm/bochs/bochs_kms.c | 1 + drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 + drivers/gpu/drm/bridge/nwl-dsi.c | 5 - drivers/gpu/drm/drm_fb_helper.c| 6 +- drivers/gpu/drm/drm_gem.c | 10 -- drivers/gpu/drm/drm_mipi_dbi.c | 2 +- drivers/gpu/drm/drm_of.c | 4 +--- drivers/gpu/drm/mcde/mcde_display.c| 11 --- drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 6 +++--- drivers/gpu/drm/panel/panel-simple.c | 16 +++- include/drm/drm_mode_config.h | 12 11 files changed, 51 insertions(+), 23 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 28/66] drm/i915/gem: Replace i915_gem_object.mm.mutex with reservation_ww_class
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. control all such allocations with the
reservation_ww_class. Currently, this is under the purview of the
obj->mm.mutex, and while obj->mm remains an embedded struct we can
"simply" switch to using the reservation_ww_class obj->base.resv->lock
The major consequence is the impact on the shrinker paths as the
reservation_ww_class is used to wrap allocations, and a ww_mutex does
not support subclassing so we cannot do our usual trick of knowing that
we never recurse inside the shrinker and instead have to finish the
reclaim with a trylock. This may result in us failing to release the
pages after having released the vma. This will have to do until a
better
idea comes along.
However, this step only converts the mutex over and continues to treat
everything as a single allocation and pinning the pages. With the
ww_mutex in place we can remove the temporary pinning, as we can then
reserve all storage en masse.
One last thing to do: kill the implict page pinning for active vma.
This will require us to invalidate the vma->pages when the backing
store
is removed (and we expect that while the vma is active, we mark the
backing store as active so that it cannot be removed while the HW is
busy.)
Signed-off-by: Chris Wilson
[snip]
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index dc8f052a0ffe..4e928103a38f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -47,10 +47,7 @@ static bool unsafe_drop_pages(struct
drm_i915_gem_object *obj,
if (!(shrink & I915_SHRINK_BOUND))
flags = I915_GEM_OBJECT_UNBIND_TEST;
- if (i915_gem_object_unbind(obj, flags) == 0)
- __i915_gem_object_put_pages(obj);
-
- return !i915_gem_object_has_pages(obj);
+ return i915_gem_object_unbind(obj, flags) == 0;
}
static void try_to_writeback(struct drm_i915_gem_object *obj,
@@ -199,14 +196,14 @@ i915_gem_shrink(struct drm_i915_private *i915,
spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
- if (unsafe_drop_pages(obj, shrink)) {
- /* May arrive from get_pages on another bo */
- mutex_lock(&obj->mm.lock);
+ if (unsafe_drop_pages(obj, shrink) &&
+ i915_gem_object_trylock(obj)) {
Why trylock? Because of the nesting? In that case, still use ww ctx
if provided please
By "if provided" you mean for code paths where we are calling the
shrinker ourselves, as opposed to reclaim, like shmem_get_pages?
That indeed sounds like the right thing to do, since all the get_pages
from execbuf are in the reservation phase, collecting a list of GEM
objects to lock, the ones to shrink sound like should be on that list.
+ __i915_gem_object_put_pages(obj);
if (!i915_gem_object_has_pages(obj)) {
try_to_writeback(obj, shrink);
count += obj->base.size >> PAGE_SHIFT;
}
- mutex_unlock(&obj->mm.lock);
+ i915_gem_object_unlock(obj);
}
scanned += obj->base.size >> PAGE_SHIFT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
index ff72ee2fd9cd..ac12e1c20e66 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
@@ -265,7 +265,6 @@ i915_gem_object_set_tiling(struct
drm_i915_gem_object *obj,
* pages to prevent them being swapped out and causing corruption
* due to the change in swizzling.
*/
- mutex_lock(&obj->mm.lock);
if (i915_gem_object_has_pages(obj) &&
obj->mm.madv == I915_MADV_WILLNEED &&
i915->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
@@ -280,7 +279,6 @@ i915_gem_object_set_tiling(struct
drm_i915_gem_object *obj,
obj->mm.quirked = true;
}
}
- mutex_unlock(&obj->mm.lock);
spin_lock(&obj->vma.lock);
for_each_ggtt_vma(vma, obj) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index e946032b13e4..80907c00c6fd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -129,8 +129,15 @@ userptr_mn_invalidate_range_start(struct
mmu_notifier *_mn,
ret = i915_gem_object_unbind(obj,
I915_GEM_OBJECT_UNBIND_ACTIVE |
I915_GEM_OBJECT_UNBIND_BARRIER);
- if (ret == 0)
- ret = __i915_gem_object_put_pages(obj);
+ if (ret == 0) {
+ /* ww_mutex and mmu_notifier is fs_reclaim tainted */
+ if (i915_gem_ob
[Intel-gfx] Flashing display after link training failure (Bug 1378)
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 Whiskey Lake tablet eDP display. There is a flash of the screen and then it goes black. This repeats probably until the display goes into DPMS again. The system is sluggish when this happens. i915 :00:02.0: [drm:intel_dp_start_link_train [i915]] Channel equalization failed 5 times i915 :00:02.0: [drm:intel_dp_start_link_train [i915]] [CONNECTOR:95:eDP-1] Link Training failed at link rate = 27, lane count = 2 Right now I have a hack to just return success from intel_dp_link_training_channel_equalization() after the 5 failures and the display seems to be usable. The issue seems to be that while Lane 0 succeeds in link training, Lane 1 does not. The system boots up with a usable display and seems to keep working as long as it doesn't go into DPMS. And to repeat the previous paragraph, hacking in "success", even though Lane 1 hasn't succeeded, seems to give a working display after resuming from DPMS. More details are in the bug. Any thoughts or suggestions are greatly appreciated. Thanks, Jason ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
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 -> dma_resv -> shrinkers -> i_mmap_lock_write I hope that's not inconsistent with anything mm or fs does, adding relevant people. Signed-off-by: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: Dave Chinner Cc: Qian Cai Cc: linux-...@vger.kernel.org Cc: linux-fsde...@vger.kernel.org Cc: Thomas Hellström (Intel) Cc: Andrew Morton Cc: Jason Gunthorpe Cc: linux...@kvack.org Cc: linux-r...@vger.kernel.org Cc: Maarten Lankhorst --- drivers/dma-buf/dma-resv.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index 0e6675ec1d11..9678162a4ac5 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -104,12 +104,14 @@ static int __init dma_resv_lockdep(void) struct mm_struct *mm = mm_alloc(); struct ww_acquire_ctx ctx; struct dma_resv obj; + struct address_space mapping; int ret; if (!mm) return -ENOMEM; dma_resv_init(&obj); + address_space_init_once(&mapping); mmap_read_lock(mm); ww_acquire_init(&ctx, &reservation_ww_class); @@ -117,6 +119,9 @@ static int __init dma_resv_lockdep(void) if (ret == -EDEADLK) dma_resv_lock_slow(&obj, &ctx); fs_reclaim_acquire(GFP_KERNEL); + /* for unmap_mapping_range on trylocked buffer objects in shrinkers */ + i_mmap_lock_write(&mapping); + i_mmap_unlock_write(&mapping); #ifdef CONFIG_MMU_NOTIFIER lock_map_acquire(&__mmu_notifier_invalidate_range_start_map); __dma_fence_might_wait(); -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
== 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: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 23 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/66] drm/i915: Keep the most recently used active-fence upon discard
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 node for reuse */
> > + if (ref->cache) {
> > + /* Discard all other nodes in the tree */
> > + rb_erase(&ref->cache->node, &ref->tree);
> > + root = ref->tree;
> > +
> > + /* Rebuild the tree with only the cached node */
> > + rb_link_node(&ref->cache->node, NULL, &ref->tree.rb_node);
> > + rb_insert_color(&ref->cache->node, &ref->tree);
> > + GEM_BUG_ON(ref->tree.rb_node != &ref->cache->node);
> > + }
> >
> > spin_unlock_irqrestore(&ref->tree_lock, flags);
> >
> > @@ -156,6 +168,7 @@ __active_retire(struct i915_active *ref)
> > /* ... except if you wait on it, you must manage your own references!
> > */
> > wake_up_var(ref);
> >
> > + /* Finally free the discarded timeline tree */
> > rbtree_postorder_for_each_entry_safe(it, n, &root, node) {
> > GEM_BUG_ON(i915_active_fence_isset(&it->base));
> > kmem_cache_free(global.slab_cache, it);
>
> Here it frees everything.. so how does ref->cache, being in the tree,
> survives?
This is the old root which does not contain ref->cache, as we moved that
to become the new tree.
/* Discard all other nodes in the tree */
rb_erase(&ref->cache->node, &ref->tree);
root = ref->tree;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/66] drm/i915: Make the stale cached active node available for any timeline
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 is not trivial
> > on 32b, so for compatibility we just fallback to keeping the cached node
> > pointing to the MRU timeline.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_active.c | 21 +++--
> > 1 file changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_active.c
> > b/drivers/gpu/drm/i915/i915_active.c
> > index 0854b1552bc1..6737b5615c0c 100644
> > --- a/drivers/gpu/drm/i915/i915_active.c
> > +++ b/drivers/gpu/drm/i915/i915_active.c
> > @@ -157,6 +157,10 @@ __active_retire(struct i915_active *ref)
> > rb_link_node(&ref->cache->node, NULL, &ref->tree.rb_node);
> > rb_insert_color(&ref->cache->node, &ref->tree);
> > GEM_BUG_ON(ref->tree.rb_node != &ref->cache->node);
> > +
> > + /* Make the cached node available for reuse with any timeline
> > */
> > + if (IS_ENABLED(CONFIG_64BIT))
> > + ref->cache->timeline = 0; /* needs cmpxchg(u64) */
>
> Or when fence context wraps shock horror.
I more concerned about that we use timeline:0 as a special unordered
timeline. It's reserved by use in the dma_fence_stub, and everything
will start to break when the timelines wrap. The earliest causalities
will be the kernel_context timelines which are also very special indices
for the barriers.
>
> > }
> >
> > spin_unlock_irqrestore(&ref->tree_lock, flags);
> > @@ -235,9 +239,22 @@ static struct active_node *__active_lookup(struct
> > i915_active *ref, u64 idx)
> > {
> > struct active_node *it;
> >
> > + GEM_BUG_ON(idx == 0); /* 0 is the unordered timeline, rsvd for cache
> > */
> > +
> > it = READ_ONCE(ref->cache);
> > - if (it && it->timeline == idx)
> > - return it;
> > + if (it) {
> > + u64 cached = READ_ONCE(it->timeline);
> > +
> > + if (cached == idx)
> > + return it;
> > +
> > +#ifdef CONFIG_64BIT /* for cmpxchg(u64) */
> > + if (!cached && !cmpxchg(&it->timeline, 0, idx)) {
> > + GEM_BUG_ON(i915_active_fence_isset(&it->base));
> > + return it;
>
> cpmxchg suggests this needs to be atomic, however above the check for
> equality comes from a separate read.
That's fine, and quite common to avoid cmpxchg if the current value
already does not match the expected condition.
> Since there is a lookup code path under the spinlock, perhaps the
> unlocked lookup could just fail, and then locked lookup could re-assign
> the timeline without the need for cmpxchg?
The unlocked/locked lookup are the same routine. You pointed that out
:-p
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
== 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
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/index.html
Known issues
Here are the changes found in Patchwork_18248 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][5] ([i915#1888]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-apl-guc: [DMESG-WARN][7] ([i915#1635] / [i915#1982]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-apl-guc/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/fi-apl-guc/igt@i915_module_l...@reload.html
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-bsw-kefka/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/fi-bsw-kefka/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][16] ([i915#62] / [i915#92]) +4 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (41 -> 37)
--
Additional (1): fi-tgl-y
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper
Build changes
-
* Linux: CI_DRM_8804 -> Patchwork_18248
CI-20190529: 20190529
CI_DRM_8804: 943d034c433e5be93076cf51fd8ea5b4d7644e8b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5749: 2fef871e791ceab7841b899691c443167550173d @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18248: dca1dc9ea07c1e389ab5377902f01adcd6d4d6ec @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
dca1dc9ea07c dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/index.html
___
Intel-
Re: [Intel-gfx] [PATCH 08/66] drm/i915: Make the stale cached active node available for any timeline
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 cmpxchg(u64) and so is not trivial
> > on 32b, so for compatibility we just fallback to keeping the cached node
> > pointing to the MRU timeline.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_active.c | 21 +++--
> > 1 file changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_active.c
> > b/drivers/gpu/drm/i915/i915_active.c
> > index 0854b1552bc1..6737b5615c0c 100644
> > --- a/drivers/gpu/drm/i915/i915_active.c
> > +++ b/drivers/gpu/drm/i915/i915_active.c
> > @@ -157,6 +157,10 @@ __active_retire(struct i915_active *ref)
> > rb_link_node(&ref->cache->node, NULL, &ref->tree.rb_node);
> > rb_insert_color(&ref->cache->node, &ref->tree);
> > GEM_BUG_ON(ref->tree.rb_node != &ref->cache->node);
> > +
> > + /* Make the cached node available for reuse with any timeline
> > */
> > + if (IS_ENABLED(CONFIG_64BIT))
> > + ref->cache->timeline = 0; /* needs cmpxchg(u64) */
> > }
> >
> > spin_unlock_irqrestore(&ref->tree_lock, flags);
> > @@ -235,9 +239,22 @@ static struct active_node *__active_lookup(struct
> > i915_active *ref, u64 idx)
> > {
> > struct active_node *it;
> >
> > + GEM_BUG_ON(idx == 0); /* 0 is the unordered timeline, rsvd for cache
> > */
> > +
> > it = READ_ONCE(ref->cache);
> > - if (it && it->timeline == idx)
> > - return it;
> > + if (it) {
> > + u64 cached = READ_ONCE(it->timeline);
> > +
> > + if (cached == idx)
> > + return it;
> > +
> > +#ifdef CONFIG_64BIT /* for cmpxchg(u64) */
> > + if (!cached && !cmpxchg(&it->timeline, 0, idx)) {
>
> Doesn't cmpxchg() already do an unlocked compare before attempting the
> locked cycle?
It goes straight to the locked instruction, as it's usually used at
the end of a loop that looks at the old value (and now try_cmpxchg). You
can see the difference in perf, as the cmpxchg stands out like a sore
thumb.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/66] drm/i915: Provide a fastpath for waiting on vma bindings
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 the RCU protection.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_active.h | 15 +++
> > drivers/gpu/drm/i915/i915_vma.c| 9 +++--
> > 2 files changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_active.h
> > b/drivers/gpu/drm/i915/i915_active.h
> > index b9e0394e2975..fb165d3f01cf 100644
> > --- a/drivers/gpu/drm/i915/i915_active.h
> > +++ b/drivers/gpu/drm/i915/i915_active.h
> > @@ -231,4 +231,19 @@ struct i915_active *i915_active_create(void);
> > struct i915_active *i915_active_get(struct i915_active *ref);
> > void i915_active_put(struct i915_active *ref);
> >
> > +static inline int __i915_request_await_exclusive(struct i915_request *rq,
> > + struct i915_active *active)
> > +{
> > + struct dma_fence *fence;
> > + int err = 0;
> > +
> > + fence = i915_active_fence_get(&active->excl);
> > + if (fence) {
> > + err = i915_request_await_dma_fence(rq, fence);
> > + dma_fence_put(fence);
> > + }
> > +
> > + return err;
> > +}
> > +
> > #endif /* _I915_ACTIVE_H_ */
> > diff --git a/drivers/gpu/drm/i915/i915_vma.c
> > b/drivers/gpu/drm/i915/i915_vma.c
> > index bc64f773dcdb..cd12047c7791 100644
> > --- a/drivers/gpu/drm/i915/i915_vma.c
> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > @@ -1167,6 +1167,12 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
> > list_del(&vma->obj->userfault_link);
> > }
> >
> > +static int
> > +__i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
> > +{
> > + return __i915_request_await_exclusive(rq, &vma->active);
> > +}
> > +
> > int __i915_vma_move_to_active(struct i915_vma *vma, struct i915_request
> > *rq)
> > {
> > int err;
> > @@ -1174,8 +1180,7 @@ int __i915_vma_move_to_active(struct i915_vma *vma,
> > struct i915_request *rq)
> > GEM_BUG_ON(!i915_vma_is_pinned(vma));
> >
> > /* Wait for the vma to be bound before we start! */
> > - err = i915_request_await_active(rq, &vma->active,
> > - I915_ACTIVE_AWAIT_EXCL);
> > + err = __i915_request_await_bind(rq, vma);
> > if (err)
> > return err;
> >
> >
>
> Looks like for like, apart from missing i915_active_acquire_if_busy
> across the operation. Remind me please what is acquire/release
> protecting against? :)
To protect the rbtree walk. So, this is the function we started with for
active_await, but when we added the option to walk the entire rbtree as
well, we pulled it all under a single acquire/release. perf suggests
that was a mistake if all we frequently want to do is grab the exclusive
fence for an await.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/66] drm/i915: Preallocate stashes for vma page-directories
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 have to assume the > > worst case, even before we know the final layout, and always allocate > > enough page directories for this object, even when there will be overlap. > > This unfortunately can be quite expensive, especially as we have to > > clear/reset the page directories and DMA pages, but it should only be > > required during early phases of a workload when new objects are being > > discovered, or after memory/eviction pressure when we need to rebind. > > Once we reach steady state, the objects should not be moved and we no > > longer need to preallocating the pages tables. > > > > It should be noted that the lifetime for the page directories DMA is > > more or less decoupled from individual fences as they will be shared > > across objects across timelines. > > > > v2: Only allocate enough PD space for the PTE we may use, we do not need > > to allocate PD that will be left as scratch. > > v3: Store the shift unto the first PD level to encapsulate the different > > PTE counts for gen6/gen8. > > > > Signed-off-by: Chris Wilson > > Cc: Matthew Auld > > --- > > .../gpu/drm/i915/gem/i915_gem_client_blt.c| 11 +-- > > drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 40 - > > drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 78 + > > drivers/gpu/drm/i915/gt/intel_ggtt.c | 60 ++ > > drivers/gpu/drm/i915/gt/intel_gtt.h | 46 ++ > > drivers/gpu/drm/i915/gt/intel_ppgtt.c | 83 --- > > drivers/gpu/drm/i915/i915_vma.c | 27 +++--- > > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 60 -- > > drivers/gpu/drm/i915/selftests/mock_gtt.c | 22 ++--- > > 9 files changed, 237 insertions(+), 190 deletions(-) > > Hi, Chris, > > Overall looks good, but a question: Why can't we perform page-table > memory allocation on demand when needed? We need to allocate device memory for the page tables. The intention here is gather up all the resource requirements for an operation and reserve them in a single pass. > Are we then under a mutex that we also take during reclaim? Yes, the vm->mutex is used during the shrinker to revoke the GPU bindings before returning memory to the system. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/66] drm/i915/gem: Don't drop the timeline lock during execbuf
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
between our own relocation request and execution in the ring.
A second, major benefit, is that it allows us to preserve a large chunk
of the ringbuffer for our exclusive use; which should virtually
eliminate the threat of hitting a wait_for_space during request
construction -- although we should have already dropped other
contentious locks at that point.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 413 +++---
.../i915/gem/selftests/i915_gem_execbuffer.c | 24 +-
2 files changed, 281 insertions(+), 156 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 719ba9fe3e85..af3499aafd22 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -259,6 +259,8 @@ struct i915_execbuffer {
bool has_fence : 1;
bool needs_unfenced : 1;
+ struct intel_context *ce;
+
struct i915_vma *target;
struct i915_request *rq;
struct i915_vma *rq_vma;
@@ -639,6 +641,35 @@ static int eb_reserve_vma(const struct
i915_execbuffer *eb,
return 0;
}
+static void retire_requests(struct intel_timeline *tl)
+{
+ struct i915_request *rq, *rn;
+
+ list_for_each_entry_safe(rq, rn, &tl->requests, link)
+ if (!i915_request_retire(rq))
+ break;
+}
+
+static int wait_for_timeline(struct intel_timeline *tl)
+{
+ do {
+ struct dma_fence *fence;
+ int err;
+
+ fence = i915_active_fence_get(&tl->last_request);
+ if (!fence)
+ return 0;
+
+ err = dma_fence_wait(fence, true);
+ dma_fence_put(fence);
+ if (err)
+ return err;
+
+ /* Retiring may trigger a barrier, requiring an extra pass */
+ retire_requests(tl);
+ } while (1);
+}
+
static int eb_reserve(struct i915_execbuffer *eb)
{
const unsigned int count = eb->buffer_count;
@@ -646,7 +677,6 @@ static int eb_reserve(struct i915_execbuffer *eb)
struct list_head last;
struct eb_vma *ev;
unsigned int i, pass;
- int err = 0;
/*
* Attempt to pin all of the buffers into the GTT.
@@ -662,18 +692,37 @@ static int eb_reserve(struct i915_execbuffer *eb)
* room for the earlier objects *unless* we need to defragment.
*/
- if (mutex_lock_interruptible(&eb->i915->drm.struct_mutex))
- return -EINTR;
-
pass = 0;
do {
+ int err = 0;
+
+ /*
+ * We need to hold one lock as we bind all the vma so that
+ * we have a consistent view of the entire vm and can plan
+ * evictions to fill the whole GTT. If we allow a second
+ * thread to run as we do this, it will either unbind
+ * everything we want pinned, or steal space that we need for
+ * ourselves. The closer we are to a full GTT, the more likely
+ * such contention will cause us to fail to bind the workload
+ * for this batch. Since we know at this point we need to
+ * find space for new buffers, we know that extra pressure
+ * from contention is likely.
+ *
+ * In lieu of being able to hold vm->mutex for the entire
+ * sequence (it's complicated!), we opt for struct_mutex.
+ */
+ if (mutex_lock_interruptible(&eb->i915->drm.struct_mutex))
+ return -EINTR;
+
With TTM, an idea that has been around for a long time is to let the
reservations resolve this. I don't think that's in place yet, though,
due to the fact that eviction / unbinding still requires a trylock
reservation and also because the evictions are not batched but
performed one by one with the evicted objects' reservations dropped
immediately after eviction. Having reservations resolve this could
perhaps be something we could aim for in the long run as well?
Unrelated batches would then never contend.
In the meantime would it make sense to introduce a new device-wide mutex
to avoid completely unrelated contention with the struct_mutex?
Actually I see this is changed later in the series...
/Thomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/66] drm/i915: Preallocate stashes for vma page-directories
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 locking rework > prerequisites in one series with cover letter, and most importantly the > major part of the locking rework (only) with a more elaborate cover > letter discussing, if not trivial, how each patch fits in and on design > and future directions, Questions that I have stumbled on so far (being a > new-to-the-driver reviewer): The locking depend on the former work to reduce the impact. It's still a major issue that we introduce a broad lock that is held for several hundred milliseconds across many objects that stalls game&compositor. > - When are memory allocations disallowed? If we need to pre-allocate in > execbuf, when? why? That should be mentioned in the code. > - When is the request dma-fence published? There a big comment to that effect. > - Do we need to keep cpu asynchronous execbuf tasks after this? why? Keep? Oh, you mean not immediately discard after publishing them, but why we need them. Same reason as we need them before. > - What about userptr pinning ending up in the dma_fence critical path? It's in the user critical path (the shortest path to perform their sequence of operations), but it's before the dma-fence itself. I say that's a particularly nasty false claim that it is not on the critical path, but being where it is circumvents the whole argument. > And then move anything non-related to separate series? Not related to what? Development of i915? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/66] drm/i915/gem: Don't drop the timeline lock during execbuf
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 relocation request in
> > between our own relocation request and execution in the ring.
> >
> > A second, major benefit, is that it allows us to preserve a large chunk
> > of the ringbuffer for our exclusive use; which should virtually
> > eliminate the threat of hitting a wait_for_space during request
> > construction -- although we should have already dropped other
> > contentious locks at that point.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 413 +++---
> > .../i915/gem/selftests/i915_gem_execbuffer.c | 24 +-
> > 2 files changed, 281 insertions(+), 156 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 719ba9fe3e85..af3499aafd22 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -259,6 +259,8 @@ struct i915_execbuffer {
> > bool has_fence : 1;
> > bool needs_unfenced : 1;
> >
> > + struct intel_context *ce;
> > +
> > struct i915_vma *target;
> > struct i915_request *rq;
> > struct i915_vma *rq_vma;
> > @@ -639,6 +641,35 @@ static int eb_reserve_vma(const struct i915_execbuffer
> > *eb,
> > return 0;
> > }
> >
> > +static void retire_requests(struct intel_timeline *tl)
> > +{
> > + struct i915_request *rq, *rn;
> > +
> > + list_for_each_entry_safe(rq, rn, &tl->requests, link)
> > + if (!i915_request_retire(rq))
> > + break;
> > +}
> > +
> > +static int wait_for_timeline(struct intel_timeline *tl)
> > +{
> > + do {
> > + struct dma_fence *fence;
> > + int err;
> > +
> > + fence = i915_active_fence_get(&tl->last_request);
> > + if (!fence)
> > + return 0;
> > +
> > + err = dma_fence_wait(fence, true);
> > + dma_fence_put(fence);
> > + if (err)
> > + return err;
> > +
> > + /* Retiring may trigger a barrier, requiring an extra pass */
> > + retire_requests(tl);
> > + } while (1);
> > +}
> > +
> > static int eb_reserve(struct i915_execbuffer *eb)
> > {
> > const unsigned int count = eb->buffer_count;
> > @@ -646,7 +677,6 @@ static int eb_reserve(struct i915_execbuffer *eb)
> > struct list_head last;
> > struct eb_vma *ev;
> > unsigned int i, pass;
> > - int err = 0;
> >
> > /*
> >* Attempt to pin all of the buffers into the GTT.
> > @@ -662,18 +692,37 @@ static int eb_reserve(struct i915_execbuffer *eb)
> >* room for the earlier objects *unless* we need to defragment.
> >*/
> >
> > - if (mutex_lock_interruptible(&eb->i915->drm.struct_mutex))
> > - return -EINTR;
> > -
> > pass = 0;
> > do {
> > + int err = 0;
> > +
> > + /*
> > + * We need to hold one lock as we bind all the vma so that
> > + * we have a consistent view of the entire vm and can plan
> > + * evictions to fill the whole GTT. If we allow a second
> > + * thread to run as we do this, it will either unbind
> > + * everything we want pinned, or steal space that we need for
> > + * ourselves. The closer we are to a full GTT, the more likely
> > + * such contention will cause us to fail to bind the workload
> > + * for this batch. Since we know at this point we need to
> > + * find space for new buffers, we know that extra pressure
> > + * from contention is likely.
> > + *
> > + * In lieu of being able to hold vm->mutex for the entire
> > + * sequence (it's complicated!), we opt for struct_mutex.
> > + */
> > + if (mutex_lock_interruptible(&eb->i915->drm.struct_mutex))
> > + return -EINTR;
> > +
>
> With TTM, an idea that has been around for a long time is to let the
> reservations resolve this. I don't think that's in place yet, though,
> due to the fact that eviction / unbinding still requires a trylock
> reservation and also because the evictions are not batched but performed
> one by one with the evicted objects' reservations dropped immediately
> after eviction. Having reservations resolve this could perhaps be
> something we could aim for in the long run as well? Unrelated batches
> would then never contend.
>
> In the meantime would it make sense to introduce a new device-wide mutex
> to avoid
Re: [Intel-gfx] [PATCH 16/66] drm/i915/gem: Remove the call for no-evict i915_vma_pin
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 it with a
> > i915_vma_pin_inplace() that is only allowed to reclaim the currently
> > bound location for the vma (and will never wait for a pinned resource).
> >
> > Signed-off-by: Chris Wilson
> > ---
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 69 +++
> > drivers/gpu/drm/i915/i915_vma.c | 6 +-
> > drivers/gpu/drm/i915/i915_vma.h | 2 +
> > 3 files changed, 45 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 28cf28fcf80a..0b8a26da26e5 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -452,49 +452,55 @@ static u64 eb_pin_flags(const struct
> > drm_i915_gem_exec_object2 *entry,
> > return pin_flags;
> > }
> >
> > +static bool eb_pin_vma_fence_inplace(struct eb_vma *ev)
> > +{
> > + struct i915_vma *vma = ev->vma;
> > + struct i915_fence_reg *reg = vma->fence;
> > +
> > + if (reg) {
> > + if (READ_ONCE(reg->dirty))
> > + return false;
> > +
> > + atomic_inc(®->pin_count);
>
> Why is this safe outside the vm->mutex? It otherwise seems to be
> protecting this pin count.
I was working on having the fence protected by the vma. It's important
that we do avoid the fallback scheme -- although not strictly as
important for gen2/gen3 as they do not need the ppGTT preallocations.
If I adapt find_fence() to operate against a concurrent atomic_inc()
that should dig myself out of the hold. (Another cmpxchg, oh my.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/66] drm/i915/gem: Remove the call for no-evict i915_vma_pin
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 list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Copy default modparams to mock i915_device
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 Ursulin
---
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 9a46be05425a..ce4d4303229c 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -77,6 +77,7 @@ static void mock_device_release(struct drm_device *dev)
drm_mode_config_cleanup(&i915->drm);
out:
+ i915_params_free(&i915->params);
put_device(&i915->drm.pdev->dev);
i915->drm.pdev = NULL;
}
@@ -159,6 +160,8 @@ struct drm_i915_private *mock_gem_device(void)
i915->drm.pdev = pdev;
drmm_add_final_kfree(&i915->drm, i915);
+ i915_params_copy(&i915->params, &i915_modparams);
+
intel_runtime_pm_init_early(&i915->runtime_pm);
/* Using the global GTT may ask questions about KMS users, so prepare */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 22/66] drm/i915/gem: Bind the fence async for execbuf
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 the vm->mutex exists, move the > > waiting outside of the lock into the async binding pipeline. > > Why is it we don't just move the fence binding to a separate loop after > unlocking the vm->mutex in eb_reserve_vm()? That is what is done. The work is called immediately when possible. Just the loop may be deferred if the what we need to unbind are still active. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Copy default modparams to mock i915_device (rev4)
== 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. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/66] drm/i915/gem: Pull execbuf dma resv under a single critical section
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 order to handle various
> > restrictions (such as avoiding copy_(from|to)_user and mmap_sem).
> >
> > Signed-off-by: Chris Wilson
> > ---
> > .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 168 +-
> > .../i915/gem/selftests/i915_gem_execbuffer.c | 8 +-
> > 2 files changed, 87 insertions(+), 89 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index ebabc0746d50..db433f3f18ec 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -20,6 +20,7 @@
> > #include "gt/intel_gt_pm.h"
> > #include "gt/intel_gt_requests.h"
> > #include "gt/intel_ring.h"
> > +#include "mm/i915_acquire_ctx.h"
> >
> > #include "i915_drv.h"
> > #include "i915_gem_clflush.h"
> > @@ -244,6 +245,8 @@ struct i915_execbuffer {
> > struct intel_context *context; /* logical state for the request */
> > struct i915_gem_context *gem_context; /** caller's context */
> >
> > + struct i915_acquire_ctx acquire; /** lock for _all_ DMA reservations
> > */
> > +
> > struct i915_request *request; /** our request to build */
> > struct eb_vma *batch; /** identity of the batch obj/vma */
> >
> > @@ -389,42 +392,6 @@ static void eb_vma_array_put(struct eb_vma_array *arr)
> > kref_put(&arr->kref, eb_vma_array_destroy);
> > }
> >
> > -static int
> > -eb_lock_vma(struct i915_execbuffer *eb, struct ww_acquire_ctx *acquire)
> > -{
> > - struct eb_vma *ev;
> > - int err = 0;
> > -
> > - list_for_each_entry(ev, &eb->submit_list, submit_link) {
> > - struct i915_vma *vma = ev->vma;
> > -
> > - err = ww_mutex_lock_interruptible(&vma->resv->lock, acquire);
> > - if (err == -EDEADLK) {
> > - struct eb_vma *unlock = ev, *en;
> > -
> > - list_for_each_entry_safe_continue_reverse(unlock, en,
> > -
> > &eb->submit_list,
> > -
> > submit_link) {
> > - ww_mutex_unlock(&unlock->vma->resv->lock);
> > - list_move_tail(&unlock->submit_link,
> > &eb->submit_list);
> > - }
> > -
> > - GEM_BUG_ON(!list_is_first(&ev->submit_link,
> > &eb->submit_list));
> > - err =
> > ww_mutex_lock_slow_interruptible(&vma->resv->lock,
> > -acquire);
> > - }
> > - if (err) {
> > - list_for_each_entry_continue_reverse(ev,
> > - &eb->submit_list,
> > - submit_link)
> > - ww_mutex_unlock(&ev->vma->resv->lock);
> > - break;
> > - }
> > - }
> > -
> > - return err;
> > -}
> > -
> > static int eb_create(struct i915_execbuffer *eb)
> > {
> > /* Allocate an extra slot for use by the sentinel */
> > @@ -668,6 +635,25 @@ eb_add_vma(struct i915_execbuffer *eb,
> > }
> > }
> >
> > +static int eb_lock_mm(struct i915_execbuffer *eb)
> > +{
> > + struct eb_vma *ev;
> > + int err;
> > +
> > + list_for_each_entry(ev, &eb->bind_list, bind_link) {
> > + err = i915_acquire_ctx_lock(&eb->acquire, ev->vma->obj);
> > + if (err)
> > + return err;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int eb_acquire_mm(struct i915_execbuffer *eb)
> > +{
> > + return i915_acquire_mm(&eb->acquire);
> > +}
> > +
> > struct eb_vm_work {
> > struct dma_fence_work base;
> > struct eb_vma_array *array;
> > @@ -1390,7 +1376,15 @@ static int eb_reserve_vm(struct i915_execbuffer *eb)
> > unsigned long count;
> > struct eb_vma *ev;
> > unsigned int pass;
> > - int err = 0;
> > + int err;
> > +
> > + err = eb_lock_mm(eb);
> > + if (err)
> > + return err;
> > +
> > + err = eb_acquire_mm(eb);
> > + if (err)
> > + return err;
> >
> > count = 0;
> > INIT_LIST_HEAD(&unbound);
> > @@ -1416,10 +1410,15 @@ static int eb_reserve_vm(struct i915_execbuffer *eb)
> > if (count == 0)
> > return 0;
> >
> > + /* We need to reserve page directories, release all, start over */
> > + i915_acquire_ctx_fini(&eb->acquire);
> > +
> > pass = 0;
> > do {
> > struct eb_vm_work *work;
[Intel-gfx] [CI] drm/i915/gem: Remove disordered per-file request list for throttling
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.
That is no more. We now have many timelines with a file, as many as the
user wants to construct (essentially per-engine, per-context). Each of
those run independently and so make the single list futile. Remove the
disordered list, and iterate over all the timelines to find a request to
wait on in each to satisfy the criteria that the CPU is no more than 20ms
ahead of its oldest request.
It should go without saying that the I915_GEM_THROTTLE ioctl is no
longer used as the primary means of throttling, so it makes sense to push
the complication into the ioctl where it only impacts upon its few
irregular users, rather than the execbuf/retire where everybody has to
pay the cost. Fortunately, the few users do not create vast amount of
contexts, so the loops over contexts/engines should be concise.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 13
drivers/gpu/drm/i915/gem/i915_gem_throttle.c | 67 +--
drivers/gpu/drm/i915/gt/selftest_lrc.c| 5 +-
drivers/gpu/drm/i915/i915_drv.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 6 --
drivers/gpu/drm/i915/i915_gem.c | 18 -
drivers/gpu/drm/i915/i915_request.c | 21 --
drivers/gpu/drm/i915/i915_request.h | 4 --
8 files changed, 50 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6b4ec66cb558..b7a86cdec9b5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1916,18 +1916,6 @@ static int eb_parse(struct i915_execbuffer *eb)
return err;
}
-static void
-add_to_client(struct i915_request *rq, struct drm_file *file)
-{
- struct drm_i915_file_private *file_priv = file->driver_priv;
-
- rq->file_priv = file_priv;
-
- spin_lock(&file_priv->mm.lock);
- list_add_tail(&rq->client_link, &file_priv->mm.request_list);
- spin_unlock(&file_priv->mm.lock);
-}
-
static int eb_submit(struct i915_execbuffer *eb, struct i915_vma *batch)
{
int err;
@@ -2567,7 +2555,6 @@ i915_gem_do_execbuffer(struct drm_device *dev,
trace_i915_request_queue(eb.request, eb.batch_flags);
err = eb_submit(&eb, batch);
err_request:
- add_to_client(eb.request, file);
i915_request_get(eb.request);
eb_request_add(&eb);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_throttle.c
b/drivers/gpu/drm/i915/gem/i915_gem_throttle.c
index 540ef0551789..1929d6cf4150 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_throttle.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_throttle.c
@@ -9,6 +9,7 @@
#include
#include "i915_drv.h"
+#include "i915_gem_context.h"
#include "i915_gem_ioctls.h"
#include "i915_gem_object.h"
@@ -35,9 +36,10 @@ int
i915_gem_throttle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
+ const unsigned long recent_enough = jiffies - DRM_I915_THROTTLE_JIFFIES;
struct drm_i915_file_private *file_priv = file->driver_priv;
- unsigned long recent_enough = jiffies - DRM_I915_THROTTLE_JIFFIES;
- struct i915_request *request, *target = NULL;
+ struct i915_gem_context *ctx;
+ unsigned long idx;
long ret;
/* ABI: return -EIO if already wedged */
@@ -45,27 +47,54 @@ i915_gem_throttle_ioctl(struct drm_device *dev, void *data,
if (ret)
return ret;
- spin_lock(&file_priv->mm.lock);
- list_for_each_entry(request, &file_priv->mm.request_list, client_link) {
- if (time_after_eq(request->emitted_jiffies, recent_enough))
- break;
+ rcu_read_lock();
+ xa_for_each(&file_priv->context_xa, idx, ctx) {
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
- if (target && xchg(&target->file_priv, NULL))
- list_del(&target->client_link);
+ if (!kref_get_unless_zero(&ctx->ref))
+ continue;
+ rcu_read_unlock();
- target = request;
- }
- if (target)
- i915_request_get(target);
- spin_unlock(&file_priv->mm.lock);
+ for_each_gem_engine(ce,
+ i915_gem_context_lock_engines(ctx),
+ it) {
+ struct i915_request *rq, *target = NULL;
+
+ if (!ce->timeline)
+ continue;
+
+ m
[Intel-gfx] [CI 1/2] drm/i915/gt: Disable preparser around xcs invalidations on tgl
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 between batches as we invalidate the TLB as a dose of healthy paranoia, just in case. References: https://gitlab.freedesktop.org/drm/intel/-/issues/2169 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_lrc.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 29c0fde8b4df..353b1717fe84 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -4764,14 +4764,21 @@ static int gen12_emit_flush(struct i915_request *request, u32 mode) intel_engine_mask_t aux_inv = 0; u32 cmd, *cs; + cmd = 4; + if (mode & EMIT_INVALIDATE) + cmd += 2; if (mode & EMIT_INVALIDATE) aux_inv = request->engine->mask & ~BIT(BCS0); + if (aux_inv) + cmd += 2 * hweight8(aux_inv) + 2; - cs = intel_ring_begin(request, - 4 + (aux_inv ? 2 * hweight8(aux_inv) + 2 : 0)); + cs = intel_ring_begin(request, cmd); if (IS_ERR(cs)) return PTR_ERR(cs); + if (mode & EMIT_INVALIDATE) + *cs++ = preparser_disable(true); + cmd = MI_FLUSH_DW + 1; /* We always require a command barrier so that subsequent @@ -4804,6 +4811,10 @@ static int gen12_emit_flush(struct i915_request *request, u32 mode) } *cs++ = MI_NOOP; } + + if (mode & EMIT_INVALIDATE) + *cs++ = preparser_disable(false); + intel_ring_advance(request, cs); return 0; -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Filter wake_flags passed to default_wake_function
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, these ended up in the default_wake_function
confusing the kernel/sched.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2110
Fixes: ef4688497512 ("drm/i915: Propagate fence errors")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: # v5.4+
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_sw_fence.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 295b9829e2da..4cd2038cbe35 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -164,9 +164,13 @@ static void __i915_sw_fence_wake_up_all(struct
i915_sw_fence *fence,
do {
list_for_each_entry_safe(pos, next, &x->head, entry) {
- pos->func(pos,
- TASK_NORMAL, fence->error,
- &extra);
+ int wake_flags;
+
+ wake_flags = fence->error;
+ if (pos->func == autoremove_wake_function)
+ wake_flags = 0;
+
+ pos->func(pos, TASK_NORMAL, wake_flags, &extra);
}
if (list_empty(&extra))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915/selftests: Add compiler paranoia for checking HWSP values
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 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c
b/drivers/gpu/drm/i915/gt/selftest_timeline.c
index fb5b7d3498a6..1203b7460557 100644
--- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
+++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
@@ -491,7 +491,7 @@ checked_intel_timeline_create(struct intel_gt *gt)
if (IS_ERR(tl))
return tl;
- if (*tl->hwsp_seqno != tl->seqno) {
+ if (READ_ONCE(*tl->hwsp_seqno) != tl->seqno) {
pr_err("Timeline created with incorrect breadcrumb, found %x,
expected %x\n",
*tl->hwsp_seqno, tl->seqno);
intel_timeline_put(tl);
@@ -561,9 +561,9 @@ static int live_hwsp_engine(void *arg)
for (n = 0; n < count; n++) {
struct intel_timeline *tl = timelines[n];
- if (!err && *tl->hwsp_seqno != n) {
- pr_err("Invalid seqno stored in timeline %lu @ %x,
found 0x%x\n",
- n, tl->hwsp_offset, *tl->hwsp_seqno);
+ if (!err && READ_ONCE(*tl->hwsp_seqno) != n) {
+ GEM_TRACE_ERR("Invalid seqno:%lu stored in timeline
%llu @ %x, found 0x%x\n",
+ n, tl->fence_context, tl->hwsp_offset,
*tl->hwsp_seqno);
GEM_TRACE_DUMP();
err = -EINVAL;
}
@@ -633,9 +633,9 @@ static int live_hwsp_alternate(void *arg)
for (n = 0; n < count; n++) {
struct intel_timeline *tl = timelines[n];
- if (!err && *tl->hwsp_seqno != n) {
- pr_err("Invalid seqno stored in timeline %lu @ %x,
found 0x%x\n",
- n, tl->hwsp_offset, *tl->hwsp_seqno);
+ if (!err && READ_ONCE(*tl->hwsp_seqno) != n) {
+ GEM_TRACE_ERR("Invalid seqno:%lu stored in timeline
%llu @ %x, found 0x%x\n",
+ n, tl->fence_context, tl->hwsp_offset,
*tl->hwsp_seqno);
GEM_TRACE_DUMP();
err = -EINVAL;
}
@@ -733,7 +733,8 @@ static int live_hwsp_wrap(void *arg)
goto out;
}
- if (*hwsp_seqno[0] != seqno[0] || *hwsp_seqno[1] != seqno[1]) {
+ if (READ_ONCE(*hwsp_seqno[0]) != seqno[0] ||
+ READ_ONCE(*hwsp_seqno[1]) != seqno[1]) {
pr_err("Bad timeline values: found (%x, %x), expected
(%x, %x)\n",
*hwsp_seqno[0], *hwsp_seqno[1],
seqno[0], seqno[1]);
@@ -966,9 +967,9 @@ static int live_hwsp_recycle(void *arg)
break;
}
- if (*tl->hwsp_seqno != count) {
- pr_err("Invalid seqno stored in timeline %lu @
tl->hwsp_offset, found 0x%x\n",
- count, *tl->hwsp_seqno);
+ if (READ_ONCE(*tl->hwsp_seqno) != count) {
+ GEM_TRACE_ERR("Invalid seqno:%lu stored in
timeline %llu @ %x found 0x%x\n",
+ count, tl->fence_context,
tl->hwsp_offset, *tl->hwsp_seqno);
GEM_TRACE_DUMP();
err = -EINVAL;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Remove gen check before calling intel_rps_boost
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
---
drivers/gpu/drm/i915/i915_request.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 679a915e9a63..e48daeef6882 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1823,11 +1823,8 @@ long i915_request_wait(struct i915_request *rq,
* but at a cost of spending more power processing the workload
* (bad for battery).
*/
- if (flags & I915_WAIT_PRIORITY) {
- if (!i915_request_started(rq) &&
- INTEL_GEN(rq->engine->i915) >= 6)
- intel_rps_boost(rq);
- }
+ if (flags & I915_WAIT_PRIORITY && !i915_request_started(rq))
+ intel_rps_boost(rq);
wait.tsk = current;
if (dma_fence_add_callback(&rq->fence, &wait.cb, request_wait_wake))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/12] drm/i915/gt: Only transfer the virtual context to the new engine if active
One more complication of preempt-to-busy with respect to the virtual
engine is that we may have retired the last request along the virtual
engine at the same time as preparing to submit the completed request to
a new engine. That submit will be shortcircuited, but not before we have
updated the context with the new register offsets and marked the virtual
engine as bound to the new engine (by calling swap on ve->siblings[]).
As we may have just retired the completed request, we may also be in the
middle of calling virtual_context_exit() to turn off the power management
associated with the virtual engine, and that in turn walks the
ve->siblings[]. If we happen to call swap() on the array as we walk, we
will call intel_engine_pm_put() twice on the same engine.
In this patch, we prevent this by only updating the bound engine after a
successful submission which weeds out the already completed requests.
Alternatively, we could walk a non-volatile array for the pm, such as
using the engine->mask. The small advantage to performing the update
after the submit is that we then only have to do a swap for active
requests.
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: "Nayana, Venkata Ramana"
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 65 ++---
1 file changed, 40 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 88a5c155154d..5e8278e8ac79 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1805,6 +1805,33 @@ static bool virtual_matches(const struct virtual_engine
*ve,
return true;
}
+static void virtual_xfer_context(struct virtual_engine *ve,
+struct intel_engine_cs *engine)
+{
+ unsigned int n;
+
+ if (likely(engine == ve->siblings[0]))
+ return;
+
+ GEM_BUG_ON(READ_ONCE(ve->context.inflight));
+ if (!intel_engine_has_relative_mmio(engine))
+ virtual_update_register_offsets(ve->context.lrc_reg_state,
+ engine);
+
+ /*
+* Move the bound engine to the top of the list for
+* future execution. We then kick this tasklet first
+* before checking others, so that we preferentially
+* reuse this set of bound registers.
+*/
+ for (n = 1; n < ve->num_siblings; n++) {
+ if (ve->siblings[n] == engine) {
+ swap(ve->siblings[n], ve->siblings[0]);
+ break;
+ }
+ }
+}
+
#define for_each_waiter(p__, rq__) \
list_for_each_entry_lockless(p__, \
&(rq__)->sched.waiters_list, \
@@ -2253,35 +2280,23 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
GEM_BUG_ON(!(rq->execution_mask & engine->mask));
WRITE_ONCE(rq->engine, engine);
- if (engine != ve->siblings[0]) {
- u32 *regs = ve->context.lrc_reg_state;
- unsigned int n;
-
- GEM_BUG_ON(READ_ONCE(ve->context.inflight));
-
- if (!intel_engine_has_relative_mmio(engine))
- virtual_update_register_offsets(regs,
- engine);
-
+ if (__i915_request_submit(rq)) {
/*
-* Move the bound engine to the top of the list
-* for future execution. We then kick this
-* tasklet first before checking others, so that
-* we preferentially reuse this set of bound
-* registers.
+* Only after we confirm that we will submit
+* this request (i.e. it has not already
+* completed), do we want to update the context.
+*
+* This serves two purposes. It avoids
+* unnecessary work if we are resubmitting an
+* already completed request after timeslicing.
+* But more importantly, it prevents us altering
+* ve->siblings[] on an idle context, where
+* we may be using ve->siblings[] in
+* virtual_context_enter / virtual_context_exit.
*/
- for (n = 1; n < ve->num_siblings; n++) {
-
[Intel-gfx] [PATCH 05/12] drm/i915/gt: Distinguish the virtual breadcrumbs from the irq breadcrumbs
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 we need to ensure that we do not actually try and
enable interrupts and the powermanagement required for them on the
virtual engine, as they will never be disabled. Instead, let's
specify the physical engine used for interrupt handler on a particular
breadcrumb.
v2: Drop b->irq_armed = true mocking for no interrupt HW
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 76 ++-
drivers/gpu/drm/i915/gt/intel_breadcrumbs.h | 36 +
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 47
drivers/gpu/drm/i915/gt/intel_engine.h| 17 -
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 3 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 31 +---
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 11 ++-
drivers/gpu/drm/i915/gt/intel_reset.c | 1 +
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 1 +
drivers/gpu/drm/i915/gt/mock_engine.c | 10 ++-
drivers/gpu/drm/i915/i915_irq.c | 1 +
drivers/gpu/drm/i915/i915_request.c | 1 +
drivers/gpu/drm/i915/i915_request.h | 4 -
16 files changed, 162 insertions(+), 95 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
create mode 100644 drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index fbdc465a5870..2ffd47a86656 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -28,6 +28,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
+#include "intel_breadcrumbs.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -55,30 +56,28 @@ static void irq_disable(struct intel_engine_cs *engine)
static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
{
- struct intel_engine_cs *engine =
- container_of(b, struct intel_engine_cs, breadcrumbs);
-
lockdep_assert_held(&b->irq_lock);
+ if (!b->irq_engine || !b->irq_armed)
+ return;
+
GEM_BUG_ON(!b->irq_enabled);
if (!--b->irq_enabled)
- irq_disable(engine);
+ irq_disable(b->irq_engine);
WRITE_ONCE(b->irq_armed, false);
- intel_gt_pm_put_async(engine->gt);
+ intel_gt_pm_put_async(b->irq_engine->gt);
}
-void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine)
+void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
{
- struct intel_breadcrumbs *b = &engine->breadcrumbs;
unsigned long flags;
if (!READ_ONCE(b->irq_armed))
return;
spin_lock_irqsave(&b->irq_lock, flags);
- if (b->irq_armed)
- __intel_breadcrumbs_disarm_irq(b);
+ __intel_breadcrumbs_disarm_irq(b);
spin_unlock_irqrestore(&b->irq_lock, flags);
}
@@ -133,13 +132,8 @@ __dma_fence_signal__notify(struct dma_fence *fence,
static void add_retire(struct intel_breadcrumbs *b, struct intel_timeline *tl)
{
- struct intel_engine_cs *engine =
- container_of(b, struct intel_engine_cs, breadcrumbs);
-
- if (unlikely(intel_engine_is_virtual(engine)))
- engine = intel_virtual_engine_get_sibling(engine, 0);
-
- intel_engine_add_retire(engine, tl);
+ if (b->irq_engine)
+ intel_engine_add_retire(b->irq_engine, tl);
}
static bool __signal_request(struct i915_request *rq, struct list_head
*signals)
@@ -164,7 +158,7 @@ static void signal_irq_work(struct irq_work *work)
spin_lock(&b->irq_lock);
- if (b->irq_armed && list_empty(&b->signalers))
+ if (list_empty(&b->signalers))
__intel_breadcrumbs_disarm_irq(b);
list_splice_init(&b->signaled_requests, &signal);
@@ -222,14 +216,12 @@ static void signal_irq_work(struct irq_work *work)
static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
{
- struct intel_engine_cs *engine =
- container_of(b, struct intel_engine_cs, breadcrumbs);
-
lockdep_assert_held(&b->irq_lock);
- if (b->irq_armed)
+
+ if (!b->irq_engine || b->irq_armed)
return;
- if (!intel_gt_pm_get_if_awake(engine->gt))
+ if (!intel_gt_pm_get_if_awake(b->irq_engine->gt))
return;
/*
@@ -249,37 +241,49 @@ static void __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
*/
if (!b->irq_enabled++)
-
[Intel-gfx] [PATCH 07/12] drm/i915/gt: Hold context/request reference while breadcrumbs are active
Currently we hold no actual reference to the request nor context while
they are attached to a breadcrumb. To avoid freeing the request/context
too early, we serialise with cancel-breadcrumbs by taking the irq
spinlock in i915_request_retire(). The alternative is to take a
reference for a new breadcrumb and release it upon signaling; removing
the more frequently hit contention point in i915_request_retire().
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 57 -
drivers/gpu/drm/i915/i915_request.c | 9 ++--
2 files changed, 47 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 9dd99969fd07..fc6f0223d2c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -29,6 +29,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
#include "intel_breadcrumbs.h"
+#include "intel_context.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -99,6 +100,22 @@ static void __intel_breadcrumbs_disarm_irq(struct
intel_breadcrumbs *b)
intel_gt_pm_put_async(b->irq_engine->gt);
}
+static void add_signaling_context(struct intel_breadcrumbs *b,
+ struct intel_context *ce)
+{
+ intel_context_get(ce);
+ list_add_tail(&ce->signal_link, &b->signalers);
+ if (list_is_first(&ce->signal_link, &b->signalers))
+ __intel_breadcrumbs_arm_irq(b);
+}
+
+static void remove_signaling_context(struct intel_breadcrumbs *b,
+struct intel_context *ce)
+{
+ list_del(&ce->signal_link);
+ intel_context_put(ce);
+}
+
static inline bool __request_completed(const struct i915_request *rq)
{
return i915_seqno_passed(__hwsp_seqno(rq), rq->fence.seqno);
@@ -107,6 +124,9 @@ static inline bool __request_completed(const struct
i915_request *rq)
__maybe_unused static bool
check_signal_order(struct intel_context *ce, struct i915_request *rq)
{
+ if (rq->context != ce)
+ return false;
+
if (!list_is_last(&rq->signal_link, &ce->signals) &&
i915_seqno_passed(rq->fence.seqno,
list_next_entry(rq, signal_link)->fence.seqno))
@@ -158,10 +178,11 @@ static bool __signal_request(struct i915_request *rq,
struct list_head *signals)
{
clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
- if (!__dma_fence_signal(&rq->fence))
+ if (!__dma_fence_signal(&rq->fence)) {
+ i915_request_put(rq);
return false;
+ }
- i915_request_get(rq);
list_add_tail(&rq->signal_link, signals);
return true;
}
@@ -209,8 +230,8 @@ static void signal_irq_work(struct irq_work *work)
/* Advance the list to the first incomplete request */
__list_del_many(&ce->signals, pos);
if (&ce->signals == pos) { /* now empty */
- list_del_init(&ce->signal_link);
add_retire(b, ce->timeline);
+ remove_signaling_context(b, ce);
}
}
}
@@ -279,6 +300,9 @@ void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
spin_lock_irqsave(&b->irq_lock, flags);
__intel_breadcrumbs_disarm_irq(b);
spin_unlock_irqrestore(&b->irq_lock, flags);
+
+ if (!list_empty(&b->signalers))
+ irq_work_queue(&b->irq_work);
}
void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
@@ -295,6 +319,8 @@ static void insert_breadcrumb(struct i915_request *rq,
if (test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags))
return;
+ i915_request_get(rq);
+
/*
* If the request is already completed, we can transfer it
* straight onto a signaled list, and queue the irq worker for
@@ -306,8 +332,6 @@ static void insert_breadcrumb(struct i915_request *rq,
return;
}
- __intel_breadcrumbs_arm_irq(b);
-
/*
* We keep the seqno in retirement order, so we can break
* inside intel_engine_signal_breadcrumbs as soon as we've
@@ -322,16 +346,19 @@ static void insert_breadcrumb(struct i915_request *rq,
* start looking for our insertion point from the tail of
* the list.
*/
- list_for_each_prev(pos, &ce->signals) {
- struct i915_request *it =
- list_entry(pos, typeof(*it), signal_link);
-
- if (i915_seqno_passed(rq->fence.seqno, it->fence.seqno))
- break;
+ if (list_empty(&ce->signals)) {
+ add_signaling_context(b, ce);
+ pos = &ce->signals;
+ } else {
+ list_for_each_prev(pos, &ce->signals) {
+ struct i9
[Intel-gfx] [PATCH 06/12] drm/i915/gt: Move intel_breadcrumbs_arm_irq earlier
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 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 2ffd47a86656..9dd99969fd07 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -54,6 +54,36 @@ static void irq_disable(struct intel_engine_cs *engine)
spin_unlock(&engine->gt->irq_lock);
}
+static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
+{
+ lockdep_assert_held(&b->irq_lock);
+
+ if (!b->irq_engine || b->irq_armed)
+ return;
+
+ if (!intel_gt_pm_get_if_awake(b->irq_engine->gt))
+ return;
+
+ /*
+* The breadcrumb irq will be disarmed on the interrupt after the
+* waiters are signaled. This gives us a single interrupt window in
+* which we can add a new waiter and avoid the cost of re-enabling
+* the irq.
+*/
+ WRITE_ONCE(b->irq_armed, true);
+
+ /*
+* Since we are waiting on a request, the GPU should be busy
+* and should have its own rpm reference. This is tracked
+* by i915->gt.awake, we can forgo holding our own wakref
+* for the interrupt as before i915->gt.awake is released (when
+* the driver is idle) we disarm the breadcrumbs.
+*/
+
+ if (!b->irq_enabled++)
+ irq_enable(b->irq_engine);
+}
+
static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
{
lockdep_assert_held(&b->irq_lock);
@@ -69,18 +99,6 @@ static void __intel_breadcrumbs_disarm_irq(struct
intel_breadcrumbs *b)
intel_gt_pm_put_async(b->irq_engine->gt);
}
-void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
-{
- unsigned long flags;
-
- if (!READ_ONCE(b->irq_armed))
- return;
-
- spin_lock_irqsave(&b->irq_lock, flags);
- __intel_breadcrumbs_disarm_irq(b);
- spin_unlock_irqrestore(&b->irq_lock, flags);
-}
-
static inline bool __request_completed(const struct i915_request *rq)
{
return i915_seqno_passed(__hwsp_seqno(rq), rq->fence.seqno);
@@ -214,36 +232,6 @@ static void signal_irq_work(struct irq_work *work)
}
}
-static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
-{
- lockdep_assert_held(&b->irq_lock);
-
- if (!b->irq_engine || b->irq_armed)
- return;
-
- if (!intel_gt_pm_get_if_awake(b->irq_engine->gt))
- return;
-
- /*
-* The breadcrumb irq will be disarmed on the interrupt after the
-* waiters are signaled. This gives us a single interrupt window in
-* which we can add a new waiter and avoid the cost of re-enabling
-* the irq.
-*/
- WRITE_ONCE(b->irq_armed, true);
-
- /*
-* Since we are waiting on a request, the GPU should be busy
-* and should have its own rpm reference. This is tracked
-* by i915->gt.awake, we can forgo holding our own wakref
-* for the interrupt as before i915->gt.awake is released (when
-* the driver is idle) we disarm the breadcrumbs.
-*/
-
- if (!b->irq_enabled++)
- irq_enable(b->irq_engine);
-}
-
struct intel_breadcrumbs *
intel_breadcrumbs_create(struct intel_engine_cs *irq_engine)
{
@@ -281,6 +269,18 @@ void intel_breadcrumbs_reset(struct intel_breadcrumbs *b)
spin_unlock_irqrestore(&b->irq_lock, flags);
}
+void intel_breadcrumbs_park(struct intel_breadcrumbs *b)
+{
+ unsigned long flags;
+
+ if (!READ_ONCE(b->irq_armed))
+ return;
+
+ spin_lock_irqsave(&b->irq_lock, flags);
+ __intel_breadcrumbs_disarm_irq(b);
+ spin_unlock_irqrestore(&b->irq_lock, flags);
+}
+
void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
{
kfree(b);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/12] drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlock
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 | 6 +++-
3 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index fc6f0223d2c8..6a278bf0fc6b 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -174,16 +174,13 @@ static void add_retire(struct intel_breadcrumbs *b,
struct intel_timeline *tl)
intel_engine_add_retire(b->irq_engine, tl);
}
-static bool __signal_request(struct i915_request *rq, struct list_head
*signals)
+static bool __signal_request(struct i915_request *rq)
{
- clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
-
if (!__dma_fence_signal(&rq->fence)) {
i915_request_put(rq);
return false;
}
- list_add_tail(&rq->signal_link, signals);
return true;
}
@@ -191,17 +188,19 @@ static void signal_irq_work(struct irq_work *work)
{
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
+ struct llist_node *signal, *sn;
struct intel_context *ce, *cn;
struct list_head *pos, *next;
- LIST_HEAD(signal);
+
+ signal = NULL;
+ if (unlikely(!llist_empty(&b->signaled_requests)))
+ signal = llist_del_all(&b->signaled_requests);
spin_lock(&b->irq_lock);
- if (list_empty(&b->signalers))
+ if (!signal && list_empty(&b->signalers))
__intel_breadcrumbs_disarm_irq(b);
- list_splice_init(&b->signaled_requests, &signal);
-
list_for_each_entry_safe(ce, cn, &b->signalers, signal_link) {
GEM_BUG_ON(list_empty(&ce->signals));
@@ -218,7 +217,11 @@ static void signal_irq_work(struct irq_work *work)
* spinlock as the callback chain may end up adding
* more signalers to the same context or engine.
*/
- __signal_request(rq, &signal);
+ clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
+ if (__signal_request(rq)) {
+ rq->signal_node.next = signal;
+ signal = &rq->signal_node;
+ }
}
/*
@@ -238,9 +241,9 @@ static void signal_irq_work(struct irq_work *work)
spin_unlock(&b->irq_lock);
- list_for_each_safe(pos, next, &signal) {
+ llist_for_each_safe(signal, sn, signal) {
struct i915_request *rq =
- list_entry(pos, typeof(*rq), signal_link);
+ llist_entry(signal, typeof(*rq), signal_node);
struct list_head cb_list;
spin_lock(&rq->lock);
@@ -264,7 +267,7 @@ intel_breadcrumbs_create(struct intel_engine_cs *irq_engine)
spin_lock_init(&b->irq_lock);
INIT_LIST_HEAD(&b->signalers);
- INIT_LIST_HEAD(&b->signaled_requests);
+ init_llist_head(&b->signaled_requests);
init_irq_work(&b->irq_work, signal_irq_work);
@@ -327,7 +330,8 @@ static void insert_breadcrumb(struct i915_request *rq,
* its signal completion.
*/
if (__request_completed(rq)) {
- if (__signal_request(rq, &b->signaled_requests))
+ if (__signal_request(rq) &&
+ llist_add(&rq->signal_node, &b->signaled_requests))
irq_work_queue(&b->irq_work);
return;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
index 8e53b9942695..3fa19820b37a 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
@@ -35,7 +35,7 @@ struct intel_breadcrumbs {
struct intel_engine_cs *irq_engine;
struct list_head signalers;
- struct list_head signaled_requests;
+ struct llist_head signaled_requests;
struct irq_work irq_work; /* for use from inside irq_lock */
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 513c12d23c2b..3cc57383f297 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -176,7 +176,11 @@ struct i915_request {
struct intel_context *context;
struct intel_ring *ring;
struct intel_timeline __rcu *timeline;
- struct list_head signal_link;
+
+ union {
+ struct list_head signal_link;
+ struct llist_node signal_node;
+ };
/*
* The
[Intel-gfx] [PATCH 02/12] drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs
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 within request submission.
The challenge in serialisation is around the unsubmission where we take
an active request that wants a breadcrumb on the signaling engine and
put it to sleep. We do not want a concurrent
dma_fence_enable_signaling() to attach a breadcrumb as we unsubmit, so
we must mark the request as no longer active before serialising with the
concurrent enable-signaling.
On retire, we serialise with the concurrent enable-signaling, but
instead of clearing ACTIVE, we mark it as SIGNALED.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 130 +---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 ---
drivers/gpu/drm/i915/i915_request.c | 39 +++---
3 files changed, 100 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 91786310c114..3d211a0c2b5a 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -220,17 +220,17 @@ static void signal_irq_work(struct irq_work *work)
}
}
-static bool __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
+static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
{
struct intel_engine_cs *engine =
container_of(b, struct intel_engine_cs, breadcrumbs);
lockdep_assert_held(&b->irq_lock);
if (b->irq_armed)
- return true;
+ return;
if (!intel_gt_pm_get_if_awake(engine->gt))
- return false;
+ return;
/*
* The breadcrumb irq will be disarmed on the interrupt after the
@@ -250,8 +250,6 @@ static bool __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
if (!b->irq_enabled++)
irq_enable(engine);
-
- return true;
}
void intel_engine_init_breadcrumbs(struct intel_engine_cs *engine)
@@ -310,57 +308,99 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine)
{
}
-bool i915_request_enable_breadcrumb(struct i915_request *rq)
+static void insert_breadcrumb(struct i915_request *rq,
+ struct intel_breadcrumbs *b)
{
- lockdep_assert_held(&rq->lock);
+ struct intel_context *ce = rq->context;
+ struct list_head *pos;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &rq->fence.flags))
- return true;
+ if (test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags))
+ return;
- if (test_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags)) {
- struct intel_breadcrumbs *b = &rq->engine->breadcrumbs;
- struct intel_context *ce = rq->context;
- struct list_head *pos;
+ __intel_breadcrumbs_arm_irq(b);
- spin_lock(&b->irq_lock);
+ /*
+* We keep the seqno in retirement order, so we can break
+* inside intel_engine_signal_breadcrumbs as soon as we've
+* passed the last completed request (or seen a request that
+* hasn't event started). We could walk the timeline->requests,
+* but keeping a separate signalers_list has the advantage of
+* hopefully being much smaller than the full list and so
+* provides faster iteration and detection when there are no
+* more interrupts required for this context.
+*
+* We typically expect to add new signalers in order, so we
+* start looking for our insertion point from the tail of
+* the list.
+*/
+ list_for_each_prev(pos, &ce->signals) {
+ struct i915_request *it =
+ list_entry(pos, typeof(*it), signal_link);
- if (test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags))
- goto unlock;
+ if (i915_seqno_passed(rq->fence.seqno, it->fence.seqno))
+ break;
+ }
+ list_add(&rq->signal_link, pos);
+ if (pos == &ce->signals) /* catch transitions from empty list */
+ list_move_tail(&ce->signal_link, &b->signalers);
+ GEM_BUG_ON(!check_signal_order(ce, rq));
- if (!__intel_breadcrumbs_arm_irq(b))
- goto unlock;
+ set_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
+}
- /*
-* We keep the seqno in retirement order, so we can break
-* inside intel_engine_signal_breadcrumbs as soon as we've
-* passed the last completed request (or seen a request that
-* hasn't event started). We could walk the timeline->requests,
[Intel-gfx] [PATCH 12/12] drm/i915: Drop i915_request.lock requirement for intel_rps_boost()
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.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_rps.c | 15 ++-
drivers/gpu/drm/i915/i915_request.c | 4 +---
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index e6a00eea0631..2a43e216e0d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -889,17 +889,15 @@ void intel_rps_park(struct intel_rps *rps)
void intel_rps_boost(struct i915_request *rq)
{
- struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
- unsigned long flags;
-
- if (i915_request_signaled(rq) || !intel_rps_is_active(rps))
+ if (i915_request_signaled(rq) || i915_request_has_waitboost(rq))
return;
/* Serializes with i915_request_retire() */
- spin_lock_irqsave(&rq->lock, flags);
- if (!i915_request_has_waitboost(rq) &&
- !dma_fence_is_signaled_locked(&rq->fence)) {
- set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags);
+ if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
+ struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
+
+ if (!intel_rps_is_active(rps))
+ return;
GT_TRACE(rps_to_gt(rps), "boost fence:%llx:%llx\n",
rq->fence.context, rq->fence.seqno);
@@ -910,7 +908,6 @@ void intel_rps_boost(struct i915_request *rq)
atomic_inc(&rps->boosts);
}
- spin_unlock_irqrestore(&rq->lock, flags);
}
int intel_rps_set(struct intel_rps *rps, u8 val)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 9172159ac633..686ee9205357 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -324,10 +324,8 @@ bool i915_request_retire(struct i915_request *rq)
spin_unlock_irq(&rq->lock);
}
- if (i915_request_has_waitboost(rq)) {
- GEM_BUG_ON(!atomic_read(&rq->engine->gt->rps.num_waiters));
+ if (test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags))
atomic_dec(&rq->engine->gt->rps.num_waiters);
- }
/*
* We only loosely track inflight requests across preemption,
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/12] drm/i915: Remove gen check before calling intel_rps_boost
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
---
drivers/gpu/drm/i915/i915_request.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 679a915e9a63..e48daeef6882 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1823,11 +1823,8 @@ long i915_request_wait(struct i915_request *rq,
* but at a cost of spending more power processing the workload
* (bad for battery).
*/
- if (flags & I915_WAIT_PRIORITY) {
- if (!i915_request_started(rq) &&
- INTEL_GEN(rq->engine->i915) >= 6)
- intel_rps_boost(rq);
- }
+ if (flags & I915_WAIT_PRIORITY && !i915_request_started(rq))
+ intel_rps_boost(rq);
wait.tsk = current;
if (dma_fence_add_callback(&rq->fence, &wait.cb, request_wait_wake))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/12] drm/i915/gt: Protect context lifetime with RCU
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 reused from the freelist within an RCU grace period. To
handle that, we have to avoid clearing members of the zombie struct.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 330 +---
drivers/gpu/drm/i915/i915_active.c | 10 +
drivers/gpu/drm/i915/i915_active.h | 2 +
drivers/gpu/drm/i915/i915_utils.h | 7 +
4 files changed, 202 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 52db2bde44a3..4e7924640ffa 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -22,7 +22,7 @@ static struct i915_global_context {
static struct intel_context *intel_context_alloc(void)
{
- return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
+ return kmem_cache_alloc(global.slab_ce, GFP_KERNEL);
}
void intel_context_free(struct intel_context *ce)
@@ -30,6 +30,177 @@ void intel_context_free(struct intel_context *ce)
kmem_cache_free(global.slab_ce, ce);
}
+static int __context_pin_state(struct i915_vma *vma)
+{
+ unsigned int bias = i915_ggtt_pin_bias(vma) | PIN_OFFSET_BIAS;
+ int err;
+
+ err = i915_ggtt_pin(vma, 0, bias | PIN_HIGH);
+ if (err)
+ return err;
+
+ err = i915_active_acquire(&vma->active);
+ if (err)
+ goto err_unpin;
+
+ /*
+* And mark it as a globally pinned object to let the shrinker know
+* it cannot reclaim the object until we release it.
+*/
+ i915_vma_make_unshrinkable(vma);
+ vma->obj->mm.dirty = true;
+
+ return 0;
+
+err_unpin:
+ i915_vma_unpin(vma);
+ return err;
+}
+
+static void __context_unpin_state(struct i915_vma *vma)
+{
+ i915_vma_make_shrinkable(vma);
+ i915_active_release(&vma->active);
+ __i915_vma_unpin(vma);
+}
+
+static int __ring_active(struct intel_ring *ring)
+{
+ int err;
+
+ err = intel_ring_pin(ring);
+ if (err)
+ return err;
+
+ err = i915_active_acquire(&ring->vma->active);
+ if (err)
+ goto err_pin;
+
+ return 0;
+
+err_pin:
+ intel_ring_unpin(ring);
+ return err;
+}
+
+static void __ring_retire(struct intel_ring *ring)
+{
+ i915_active_release(&ring->vma->active);
+ intel_ring_unpin(ring);
+}
+
+__i915_active_call
+static void __intel_context_retire(struct i915_active *active)
+{
+ struct intel_context *ce = container_of(active, typeof(*ce), active);
+
+ CE_TRACE(ce, "retire runtime: { total:%lluns, avg:%lluns }\n",
+intel_context_get_total_runtime_ns(ce),
+intel_context_get_avg_runtime_ns(ce));
+
+ set_bit(CONTEXT_VALID_BIT, &ce->flags);
+ if (ce->state)
+ __context_unpin_state(ce->state);
+
+ intel_timeline_unpin(ce->timeline);
+ __ring_retire(ce->ring);
+
+ intel_context_put(ce);
+}
+
+static int __intel_context_active(struct i915_active *active)
+{
+ struct intel_context *ce = container_of(active, typeof(*ce), active);
+ int err;
+
+ CE_TRACE(ce, "active\n");
+
+ intel_context_get(ce);
+
+ err = __ring_active(ce->ring);
+ if (err)
+ goto err_put;
+
+ err = intel_timeline_pin(ce->timeline);
+ if (err)
+ goto err_ring;
+
+ if (!ce->state)
+ return 0;
+
+ err = __context_pin_state(ce->state);
+ if (err)
+ goto err_timeline;
+
+ return 0;
+
+err_timeline:
+ intel_timeline_unpin(ce->timeline);
+err_ring:
+ __ring_retire(ce->ring);
+err_put:
+ intel_context_put(ce);
+ return err;
+}
+
+static void __intel_context_ctor(void *arg)
+{
+ struct intel_context *ce = arg;
+
+ INIT_LIST_HEAD(&ce->signal_link);
+ INIT_LIST_HEAD(&ce->signals);
+
+ atomic_set(&ce->pin_count, 0);
+ mutex_init(&ce->pin_mutex);
+
+ ce->active_count = 0;
+ i915_active_init(&ce->active,
+__intel_context_active, __intel_context_retire);
+
+ ce->inflight = NULL;
+ ce->lrc_reg_state = NULL;
+ ce->lrc.desc = 0;
+}
+
+static void
+__intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine)
+{
+ GEM_BUG_ON(!engine->cops);
+ GEM_BUG_ON(!engine->gt->vm);
+
+ kref_init(&ce->ref);
+ i915_active_reinit(&ce->active);
+ mutex_reinit(&ce->pin_mutex);
+
+ ce->engine = engine;
+ ce->ops = engine->cops;
+ ce->sseu = engine->sseu;
+
+ ce->wa_bb_page = 0;
+ ce->flags = 0;
+ ce->tag = 0;
+
+
[Intel-gfx] [PATCH 11/12] drm/i915: Drop i915_request.lock serialisation around await_start
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 able to acquire a strong reference to it.
We do not need the signal->lock crutch anymore, nor want the contention.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index c8ad14aa9d84..9172159ac633 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -976,9 +976,16 @@ i915_request_await_start(struct i915_request *rq, struct
i915_request *signal)
if (i915_request_started(signal))
return 0;
+ /*
+* The caller holds a reference on @signal, but we do not serialise
+* against it being retired and removed from the lists.
+*
+* We do not hold a reference to the request before @signal, and
+* so must be very careful to ensure that it is not _recycled_ as
+* we follow the link backwards.
+*/
fence = NULL;
rcu_read_lock();
- spin_lock_irq(&signal->lock);
do {
struct list_head *pos = READ_ONCE(signal->link.prev);
struct i915_request *prev;
@@ -1009,7 +1016,6 @@ i915_request_await_start(struct i915_request *rq, struct
i915_request *signal)
fence = &prev->fence;
} while (0);
- spin_unlock_irq(&signal->lock);
rcu_read_unlock();
if (!fence)
return 0;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/12] drm/i915/gt: Split the breadcrumb spinlock between global and contexts
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 latency. If we split the b->irq_lock by introducing a
per-context spinlock to manage the signalers within a context, we then
only need the b->irq_lock for enabling/disabling the interrupt and can
avoid taking the lock for walking the list of contexts within the signal
worker. Even with the current setup, this greatly reduces the number of
times we have to take and fight for b->irq_lock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 149 ++
drivers/gpu/drm/i915/gt/intel_context.c | 1 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
3 files changed, 84 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 6a278bf0fc6b..23fe647b50b3 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -103,17 +103,19 @@ static void __intel_breadcrumbs_disarm_irq(struct
intel_breadcrumbs *b)
static void add_signaling_context(struct intel_breadcrumbs *b,
struct intel_context *ce)
{
- intel_context_get(ce);
- list_add_tail(&ce->signal_link, &b->signalers);
- if (list_is_first(&ce->signal_link, &b->signalers))
+ lockdep_assert_held(&b->irq_lock);
+
+ list_add_rcu(&ce->signal_link, &b->signalers);
+ if (list_is_last(&ce->signal_link, &b->signalers))
__intel_breadcrumbs_arm_irq(b);
}
static void remove_signaling_context(struct intel_breadcrumbs *b,
struct intel_context *ce)
{
- list_del(&ce->signal_link);
- intel_context_put(ce);
+ spin_lock(&b->irq_lock);
+ list_del_rcu(&ce->signal_link);
+ spin_unlock(&b->irq_lock);
}
static inline bool __request_completed(const struct i915_request *rq)
@@ -189,20 +191,30 @@ static void signal_irq_work(struct irq_work *work)
struct intel_breadcrumbs *b = container_of(work, typeof(*b), irq_work);
const ktime_t timestamp = ktime_get();
struct llist_node *signal, *sn;
- struct intel_context *ce, *cn;
- struct list_head *pos, *next;
+ struct intel_context *ce;
signal = NULL;
if (unlikely(!llist_empty(&b->signaled_requests)))
signal = llist_del_all(&b->signaled_requests);
- spin_lock(&b->irq_lock);
+ if (!signal && READ_ONCE(b->irq_armed) && list_empty(&b->signalers)) {
+ if (spin_trylock(&b->irq_lock)) {
+ if (list_empty(&b->signalers))
+ __intel_breadcrumbs_disarm_irq(b);
+ spin_unlock(&b->irq_lock);
+ }
+ }
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ce, &b->signalers, signal_link) {
+ struct list_head *pos, *next;
+ bool release = false;
- if (!signal && list_empty(&b->signalers))
- __intel_breadcrumbs_disarm_irq(b);
+ if (!spin_trylock(&ce->signal_lock))
+ continue;
- list_for_each_entry_safe(ce, cn, &b->signalers, signal_link) {
- GEM_BUG_ON(list_empty(&ce->signals));
+ if (list_empty(&ce->signals))
+ goto unlock;
list_for_each_safe(pos, next, &ce->signals) {
struct i915_request *rq =
@@ -235,11 +247,16 @@ static void signal_irq_work(struct irq_work *work)
if (&ce->signals == pos) { /* now empty */
add_retire(b, ce->timeline);
remove_signaling_context(b, ce);
+ release = true;
}
}
- }
- spin_unlock(&b->irq_lock);
+unlock:
+ spin_unlock(&ce->signal_lock);
+ if (release)
+ intel_context_put(ce);
+ }
+ rcu_read_unlock();
llist_for_each_safe(signal, sn, signal) {
struct i915_request *rq =
@@ -313,9 +330,9 @@ void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
kfree(b);
}
-static void insert_breadcrumb(struct i915_request *rq,
- struct intel_breadcrumbs *b)
+static void insert_breadcrumb(struct i915_request *rq)
{
+ struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
struct intel_context *ce = rq->context;
struct list_head *pos;
@@ -351,7 +368,33 @@ static void insert_breadcrumb(struct i915_request *rq,
* the list.
*/
if (list_empty(&ce->signals)) {
+ /*
+
[Intel-gfx] [PATCH 03/12] drm/i915/gt: Replace intel_engine_transfer_stale_breadcrumbs
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 eliminate intel_engine_transfer_stale_breadcrumbs().
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 50 -
drivers/gpu/drm/i915/gt/intel_engine.h | 3 --
drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ---
drivers/gpu/drm/i915/i915_request.c | 5 +--
4 files changed, 21 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 3d211a0c2b5a..fbdc465a5870 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -142,16 +142,16 @@ static void add_retire(struct intel_breadcrumbs *b,
struct intel_timeline *tl)
intel_engine_add_retire(engine, tl);
}
-static void __signal_request(struct i915_request *rq, struct list_head
*signals)
+static bool __signal_request(struct i915_request *rq, struct list_head
*signals)
{
- GEM_BUG_ON(!test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags));
clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
if (!__dma_fence_signal(&rq->fence))
- return;
+ return false;
i915_request_get(rq);
list_add_tail(&rq->signal_link, signals);
+ return true;
}
static void signal_irq_work(struct irq_work *work)
@@ -278,32 +278,6 @@ void intel_engine_reset_breadcrumbs(struct intel_engine_cs
*engine)
spin_unlock_irqrestore(&b->irq_lock, flags);
}
-void intel_engine_transfer_stale_breadcrumbs(struct intel_engine_cs *engine,
-struct intel_context *ce)
-{
- struct intel_breadcrumbs *b = &engine->breadcrumbs;
- unsigned long flags;
-
- spin_lock_irqsave(&b->irq_lock, flags);
- if (!list_empty(&ce->signals)) {
- struct i915_request *rq, *next;
-
- /* Queue for executing the signal callbacks in the irq_work */
- list_for_each_entry_safe(rq, next, &ce->signals, signal_link) {
- GEM_BUG_ON(rq->engine != engine);
- GEM_BUG_ON(!__request_completed(rq));
-
- __signal_request(rq, &b->signaled_requests);
- }
-
- INIT_LIST_HEAD(&ce->signals);
- list_del_init(&ce->signal_link);
-
- irq_work_queue(&b->irq_work);
- }
- spin_unlock_irqrestore(&b->irq_lock, flags);
-}
-
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
{
}
@@ -317,6 +291,17 @@ static void insert_breadcrumb(struct i915_request *rq,
if (test_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags))
return;
+ /*
+* If the request is already completed, we can transfer it
+* straight onto a signaled list, and queue the irq worker for
+* its signal completion.
+*/
+ if (__request_completed(rq)) {
+ if (__signal_request(rq, &b->signaled_requests))
+ irq_work_queue(&b->irq_work);
+ return;
+ }
+
__intel_breadcrumbs_arm_irq(b);
/*
@@ -344,8 +329,11 @@ static void insert_breadcrumb(struct i915_request *rq,
if (pos == &ce->signals) /* catch transitions from empty list */
list_move_tail(&ce->signal_link, &b->signalers);
GEM_BUG_ON(!check_signal_order(ce, rq));
-
set_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags);
+
+ /* Check after attaching to irq, interrupt may have already fired. */
+ if (__request_completed(rq))
+ irq_work_queue(&b->irq_work);
}
bool i915_request_enable_breadcrumb(struct i915_request *rq)
@@ -401,7 +389,7 @@ bool i915_request_enable_breadcrumb(struct i915_request *rq)
spin_unlock(&b->irq_lock);
- return !__request_completed(rq);
+ return true;
}
void i915_request_cancel_breadcrumb(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index a9249a23903a..faf00a353e25 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -237,9 +237,6 @@ intel_engine_signal_breadcrumbs(struct intel_engine_cs
*engine)
void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
-void intel_engine_transfer_stale_breadcrumbs(struct intel_engine_cs *engine,
-struct intel_context *ce);
-
void intel_engine_print_breadcrumbs(struct intel_engine_cs *engine,
struct drm_prin
[Intel-gfx] [PATCH 2/2] drm/i915/gem: Reduce ctx->engines_mutex for get_engines()
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 a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index b5b179f96d77..f43f0ca4eec9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1862,27 +1862,6 @@ set_engines(struct i915_gem_context *ctx,
return 0;
}
-static struct i915_gem_engines *
-__copy_engines(struct i915_gem_engines *e)
-{
- struct i915_gem_engines *copy;
- unsigned int n;
-
- copy = alloc_engines(e->num_engines);
- if (!copy)
- return ERR_PTR(-ENOMEM);
-
- for (n = 0; n < e->num_engines; n++) {
- if (e->engines[n])
- copy->engines[n] = intel_context_get(e->engines[n]);
- else
- copy->engines[n] = NULL;
- }
- copy->num_engines = n;
-
- return copy;
-}
-
static int
get_engines(struct i915_gem_context *ctx,
struct drm_i915_gem_context_param *args)
@@ -1890,19 +1869,17 @@ get_engines(struct i915_gem_context *ctx,
struct i915_context_param_engines __user *user;
struct i915_gem_engines *e;
size_t n, count, size;
+ bool user_engines;
int err = 0;
- err = mutex_lock_interruptible(&ctx->engines_mutex);
- if (err)
- return err;
+ e = __context_engines_await(ctx, &user_engines);
+ if (!e)
+ return -ENOENT;
- e = NULL;
- if (i915_gem_context_user_engines(ctx))
- e = __copy_engines(i915_gem_context_engines(ctx));
- mutex_unlock(&ctx->engines_mutex);
- if (IS_ERR_OR_NULL(e)) {
+ if (!user_engines) {
+ i915_sw_fence_complete(&e->fence);
args->size = 0;
- return PTR_ERR_OR_ZERO(e);
+ return 0;
}
count = e->num_engines;
@@ -1953,7 +1930,7 @@ get_engines(struct i915_gem_context *ctx,
args->size = size;
err_free:
- free_engines(e);
+ i915_sw_fence_complete(&e->fence);
return err;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gem: Reduce ctx->engine_mutex for reading the clone source
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
src->engine_mutex, so long as we verify that nothing changed under the
read.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d0bdb6d447ed..b5b179f96d77 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -752,7 +752,8 @@ __create_context(struct drm_i915_private *i915)
}
static inline struct i915_gem_engines *
-__context_engines_await(const struct i915_gem_context *ctx)
+__context_engines_await(const struct i915_gem_context *ctx,
+ bool *user_engines)
{
struct i915_gem_engines *engines;
@@ -761,6 +762,10 @@ __context_engines_await(const struct i915_gem_context *ctx)
engines = rcu_dereference(ctx->engines);
GEM_BUG_ON(!engines);
+ if (user_engines)
+ *user_engines = i915_gem_context_user_engines(ctx);
+
+ /* successful await => strong mb */
if (unlikely(!i915_sw_fence_await(&engines->fence)))
continue;
@@ -784,7 +789,7 @@ context_apply_all(struct i915_gem_context *ctx,
struct intel_context *ce;
int err = 0;
- e = __context_engines_await(ctx);
+ e = __context_engines_await(ctx, NULL);
for_each_gem_engine(ce, e, it) {
err = fn(ce, data);
if (err)
@@ -1117,7 +1122,7 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
return err;
}
- e = __context_engines_await(ctx);
+ e = __context_engines_await(ctx, NULL);
if (!e) {
i915_active_release(&cb->base);
return -ENOENT;
@@ -2114,11 +2119,14 @@ static int copy_ring_size(struct intel_context *dst,
static int clone_engines(struct i915_gem_context *dst,
struct i915_gem_context *src)
{
- struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
- struct i915_gem_engines *clone;
+ struct i915_gem_engines *clone, *e;
bool user_engines;
unsigned long n;
+ e = __context_engines_await(src, &user_engines);
+ if (!e)
+ return -ENOENT;
+
clone = alloc_engines(e->num_engines);
if (!clone)
goto err_unlock;
@@ -2160,9 +2168,7 @@ static int clone_engines(struct i915_gem_context *dst,
}
}
clone->num_engines = n;
-
- user_engines = i915_gem_context_user_engines(src);
- i915_gem_context_unlock_engines(src);
+ i915_sw_fence_complete(&e->fence);
/* Serialised by constructor */
engines_idle_release(dst, rcu_replace_pointer(dst->engines, clone, 1));
@@ -2173,7 +2179,7 @@ static int clone_engines(struct i915_gem_context *dst,
return 0;
err_unlock:
- i915_gem_context_unlock_engines(src);
+ i915_sw_fence_complete(&e->fence);
return -ENOMEM;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/gem: Serialise debugfs i915_gem_objects with ctx->mutex
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 pointers within the context are stable and will remain valid
as we inspect their tables.
Signed-off-by: Chris Wilson
Cc: CQ Tang
Cc: Daniel Vetter
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 784219962193..ea469168cd44 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -326,6 +326,7 @@ static void print_context_stats(struct seq_file *m,
}
i915_gem_context_unlock_engines(ctx);
+ mutex_lock(&ctx->mutex);
if (!IS_ERR_OR_NULL(ctx->file_priv)) {
struct file_stats stats = {
.vm = rcu_access_pointer(ctx->vm),
@@ -346,6 +347,7 @@ static void print_context_stats(struct seq_file *m,
print_file_stats(m, name, stats);
}
+ mutex_unlock(&ctx->mutex);
spin_lock(&i915->gem.contexts.lock);
list_safe_reset_next(ctx, cn, link);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/gem: Reduce ctx->engine_mutex for reading the clone source
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
src->engine_mutex, so long as we verify that nothing changed under the
read.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 24 +
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d0bdb6d447ed..b5b179f96d77 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -752,7 +752,8 @@ __create_context(struct drm_i915_private *i915)
}
static inline struct i915_gem_engines *
-__context_engines_await(const struct i915_gem_context *ctx)
+__context_engines_await(const struct i915_gem_context *ctx,
+ bool *user_engines)
{
struct i915_gem_engines *engines;
@@ -761,6 +762,10 @@ __context_engines_await(const struct i915_gem_context *ctx)
engines = rcu_dereference(ctx->engines);
GEM_BUG_ON(!engines);
+ if (user_engines)
+ *user_engines = i915_gem_context_user_engines(ctx);
+
+ /* successful await => strong mb */
if (unlikely(!i915_sw_fence_await(&engines->fence)))
continue;
@@ -784,7 +789,7 @@ context_apply_all(struct i915_gem_context *ctx,
struct intel_context *ce;
int err = 0;
- e = __context_engines_await(ctx);
+ e = __context_engines_await(ctx, NULL);
for_each_gem_engine(ce, e, it) {
err = fn(ce, data);
if (err)
@@ -1117,7 +1122,7 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
return err;
}
- e = __context_engines_await(ctx);
+ e = __context_engines_await(ctx, NULL);
if (!e) {
i915_active_release(&cb->base);
return -ENOENT;
@@ -2114,11 +2119,14 @@ static int copy_ring_size(struct intel_context *dst,
static int clone_engines(struct i915_gem_context *dst,
struct i915_gem_context *src)
{
- struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
- struct i915_gem_engines *clone;
+ struct i915_gem_engines *clone, *e;
bool user_engines;
unsigned long n;
+ e = __context_engines_await(src, &user_engines);
+ if (!e)
+ return -ENOENT;
+
clone = alloc_engines(e->num_engines);
if (!clone)
goto err_unlock;
@@ -2160,9 +2168,7 @@ static int clone_engines(struct i915_gem_context *dst,
}
}
clone->num_engines = n;
-
- user_engines = i915_gem_context_user_engines(src);
- i915_gem_context_unlock_engines(src);
+ i915_sw_fence_complete(&e->fence);
/* Serialised by constructor */
engines_idle_release(dst, rcu_replace_pointer(dst->engines, clone, 1));
@@ -2173,7 +2179,7 @@ static int clone_engines(struct i915_gem_context *dst,
return 0;
err_unlock:
- i915_gem_context_unlock_engines(src);
+ i915_sw_fence_complete(&e->fence);
return -ENOMEM;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915: Skip taking acquire mutex for no ref->active callback
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 Hellström
---
drivers/gpu/drm/i915/i915_active.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index d960d0be5bd2..500537889e66 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -416,6 +416,14 @@ bool i915_active_acquire_if_busy(struct i915_active *ref)
return atomic_add_unless(&ref->count, 1, 0);
}
+static void __i915_active_activate(struct i915_active *ref)
+{
+ spin_lock_irq(&ref->tree_lock); /* __active_retire() */
+ if (!atomic_fetch_inc(&ref->count))
+ debug_active_activate(ref);
+ spin_unlock_irq(&ref->tree_lock);
+}
+
int i915_active_acquire(struct i915_active *ref)
{
int err;
@@ -423,19 +431,19 @@ int i915_active_acquire(struct i915_active *ref)
if (i915_active_acquire_if_busy(ref))
return 0;
+ if (!ref->active) {
+ __i915_active_activate(ref);
+ return 0;
+ }
+
err = mutex_lock_interruptible(&ref->mutex);
if (err)
return err;
if (likely(!i915_active_acquire_if_busy(ref))) {
- if (ref->active)
- err = ref->active(ref);
- if (!err) {
- spin_lock_irq(&ref->tree_lock); /* __active_retire() */
- debug_active_activate(ref);
- atomic_inc(&ref->count);
- spin_unlock_irq(&ref->tree_lock);
- }
+ err = ref->active(ref);
+ if (!err)
+ __i915_active_activate(ref);
}
mutex_unlock(&ref->mutex);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] 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.
v2: Refactor active_lookup() so it can be called again before/after
locking to resolve contention. Since we protect the rbtree until we
idle, we can do a lockfree lookup, with the caveat that if another
thread performs a concurrent insertion, the rotations from the insert
may cause us to not find our target. A second pass holding the treelock
will find the target if it exists, or the place to perform our
insertion.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 4 +-
drivers/gpu/drm/i915/i915_active.c| 150 ++
drivers/gpu/drm/i915/i915_active.h| 12 +-
4 files changed, 130 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 6b4ec66cb558..719ba9fe3e85 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1729,7 +1729,7 @@ __parser_mark_active(struct i915_vma *vma,
{
struct intel_gt_buffer_pool_node *node = vma->private;
- return i915_active_ref(&node->active, tl, fence);
+ return i915_active_ref(&node->active, tl->fence_context, fence);
}
static int
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 46d20f5f3ddc..acb43aebd669 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -484,7 +484,9 @@ __intel_timeline_get_seqno(struct intel_timeline *tl,
* free it after the current request is retired, which ensures that
* all writes into the cacheline from previous requests are complete.
*/
- err = i915_active_ref(&tl->hwsp_cacheline->active, tl, &rq->fence);
+ err = i915_active_ref(&tl->hwsp_cacheline->active,
+ tl->fence_context,
+ &rq->fence);
if (err)
goto err_cacheline;
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 500537889e66..3a728401c09c 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -28,12 +28,14 @@ static struct i915_global_active {
} global;
struct active_node {
+ struct rb_node node;
struct i915_active_fence base;
struct i915_active *ref;
- struct rb_node node;
u64 timeline;
};
+#define fetch_node(x) rb_entry(READ_ONCE(x), typeof(struct active_node), node)
+
static inline struct active_node *
node_from_active(struct i915_active_fence *active)
{
@@ -216,12 +218,9 @@ excl_retire(struct dma_fence *fence, struct dma_fence_cb
*cb)
active_retire(container_of(cb, struct i915_active, excl.cb));
}
-static struct i915_active_fence *
-active_instance(struct i915_active *ref, struct intel_timeline *tl)
+static struct active_node *__active_lookup(struct i915_active *ref, u64 idx)
{
- struct active_node *node, *prealloc;
- struct rb_node **p, *parent;
- u64 idx = tl->fence_context;
+ struct active_node *it;
/*
* We track the most recently used timeline to skip a rbtree search
@@ -230,8 +229,39 @@ active_instance(struct i915_active *ref, struct
intel_timeline *tl)
* after the previous activity has been retired, or if it matches the
* current timeline.
*/
- node = READ_ONCE(ref->cache);
- if (node && node->timeline == idx)
+ it = READ_ONCE(ref->cache);
+ if (it && it->timeline == idx)
+ return it;
+
+ BUILD_BUG_ON(offsetof(typeof(*it), node));
+
+ /* While active, the tree can only be built; not destroyed */
+ GEM_BUG_ON(i915_active_is_idle(ref));
+
+ it = fetch_node(ref->tree.rb_node);
+ while (it) {
+ if (it->timeline < idx) {
+ it = fetch_node(it->node.rb_right);
+ } else if (it->timeline > idx) {
+ it = fetch_node(it->node.rb_left);
+ } else {
+ WRITE_ONCE(ref->cache, it);
+ break;
+ }
+ }
+
+ /* NB: If the tree rotated beneath us, we may miss our target. */
+ return it;
+}
+
+static struct i915_active_fence *
+active_instance(struct i915_active *ref, u64 idx)
+{
+ struct active_node *node, *prealloc;
+ struct rb_node **p, *parent;
+
+ node = __active_lookup(ref, idx);
+ if (likely(node))
return &node->base;
/* Preallocate a replacement, just in case */
@@ -268,10 +298,9 @@ active_instance(st
[Intel-gfx] [PATCH 7/7] drm/i915: Provide a fastpath for waiting on vma bindings
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
---
drivers/gpu/drm/i915/i915_active.h | 15 +++
drivers/gpu/drm/i915/i915_vma.c| 9 +++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index b9e0394e2975..fb165d3f01cf 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -231,4 +231,19 @@ struct i915_active *i915_active_create(void);
struct i915_active *i915_active_get(struct i915_active *ref);
void i915_active_put(struct i915_active *ref);
+static inline int __i915_request_await_exclusive(struct i915_request *rq,
+struct i915_active *active)
+{
+ struct dma_fence *fence;
+ int err = 0;
+
+ fence = i915_active_fence_get(&active->excl);
+ if (fence) {
+ err = i915_request_await_dma_fence(rq, fence);
+ dma_fence_put(fence);
+ }
+
+ return err;
+}
+
#endif /* _I915_ACTIVE_H_ */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index bc64f773dcdb..cd12047c7791 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1167,6 +1167,12 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
list_del(&vma->obj->userfault_link);
}
+static int
+__i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
+{
+ return __i915_request_await_exclusive(rq, &vma->active);
+}
+
int __i915_vma_move_to_active(struct i915_vma *vma, struct i915_request *rq)
{
int err;
@@ -1174,8 +1180,7 @@ int __i915_vma_move_to_active(struct i915_vma *vma,
struct i915_request *rq)
GEM_BUG_ON(!i915_vma_is_pinned(vma));
/* Wait for the vma to be bound before we start! */
- err = i915_request_await_active(rq, &vma->active,
- I915_ACTIVE_AWAIT_EXCL);
+ err = __i915_request_await_bind(rq, vma);
if (err)
return err;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915: Add a couple of missing i915_active_fini()
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
---
drivers/gpu/drm/i915/display/intel_frontbuffer.c| 2 ++
drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c | 5 -
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 2979ed2588eb..d898b370d7a4 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -232,6 +232,8 @@ static void frontbuffer_release(struct kref *ref)
RCU_INIT_POINTER(obj->frontbuffer, NULL);
spin_unlock(&to_i915(obj->base.dev)->fb_tracking.lock);
+ i915_active_fini(&front->write);
+
i915_gem_object_put(obj);
kfree_rcu(front, rcu);
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
index 73243ba59c7d..e73854dd2fe0 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c
@@ -47,7 +47,10 @@ static int pulse_active(struct i915_active *active)
static void pulse_free(struct kref *kref)
{
- kfree(container_of(kref, struct pulse, kref));
+ struct pulse *p = container_of(kref, typeof(*p), kref);
+
+ i915_active_fini(&p->active);
+ kfree(p);
}
static void pulse_put(struct pulse *p)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915: Make the stale cached active node available for any timeline
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 MRU timeline.
Signed-off-by: Chris Wilson
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_active.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index b9bd5578ff54..03b246cb8466 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -157,6 +157,10 @@ __active_retire(struct i915_active *ref)
rb_link_node(&ref->cache->node, NULL, &ref->tree.rb_node);
rb_insert_color(&ref->cache->node, &ref->tree);
GEM_BUG_ON(ref->tree.rb_node != &ref->cache->node);
+
+ /* Make the cached node available for reuse with any timeline */
+ if (IS_ENABLED(CONFIG_64BIT))
+ ref->cache->timeline = 0; /* needs cmpxchg(u64) */
}
spin_unlock_irqrestore(&ref->tree_lock, flags);
@@ -235,6 +239,8 @@ static struct active_node *__active_lookup(struct
i915_active *ref, u64 idx)
{
struct active_node *it;
+ GEM_BUG_ON(idx == 0); /* 0 is the unordered timeline, rsvd for cache */
+
/*
* We track the most recently used timeline to skip a rbtree search
* for the common case, under typical loads we never need the rbtree
@@ -243,8 +249,17 @@ static struct active_node *__active_lookup(struct
i915_active *ref, u64 idx)
* current timeline.
*/
it = READ_ONCE(ref->cache);
- if (it && it->timeline == idx)
- return it;
+ if (it) {
+ u64 cached = READ_ONCE(it->timeline);
+
+ if (cached == idx)
+ return it;
+
+#ifdef CONFIG_64BIT /* for cmpxchg(u64) */
+ if (!cached && !cmpxchg(&it->timeline, 0, idx))
+ return it;
+#endif
+ }
BUILD_BUG_ON(offsetof(typeof(*it), node));
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915: Keep the most recently used active-fence upon discard
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 the next active reference as that is the most likely
timeline to be reused.
Signed-off-by: Chris Wilson
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_active.c | 27 ---
drivers/gpu/drm/i915/i915_active.h | 4
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 3a728401c09c..b9bd5578ff54 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -130,8 +130,8 @@ static inline void debug_active_assert(struct i915_active
*ref) { }
static void
__active_retire(struct i915_active *ref)
{
+ struct rb_root root = RB_ROOT;
struct active_node *it, *n;
- struct rb_root root;
unsigned long flags;
GEM_BUG_ON(i915_active_is_idle(ref));
@@ -143,9 +143,21 @@ __active_retire(struct i915_active *ref)
GEM_BUG_ON(rcu_access_pointer(ref->excl.fence));
debug_active_deactivate(ref);
- root = ref->tree;
- ref->tree = RB_ROOT;
- ref->cache = NULL;
+ /* 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 node for reuse */
+ if (ref->cache) {
+ /* Discard all other nodes in the tree */
+ rb_erase(&ref->cache->node, &ref->tree);
+ root = ref->tree;
+
+ /* Rebuild the tree with only the cached node */
+ rb_link_node(&ref->cache->node, NULL, &ref->tree.rb_node);
+ rb_insert_color(&ref->cache->node, &ref->tree);
+ GEM_BUG_ON(ref->tree.rb_node != &ref->cache->node);
+ }
spin_unlock_irqrestore(&ref->tree_lock, flags);
@@ -156,6 +168,7 @@ __active_retire(struct i915_active *ref)
/* ... except if you wait on it, you must manage your own references! */
wake_up_var(ref);
+ /* Finally free the discarded timeline tree */
rbtree_postorder_for_each_entry_safe(it, n, &root, node) {
GEM_BUG_ON(i915_active_fence_isset(&it->base));
kmem_cache_free(global.slab_cache, it);
@@ -745,16 +758,16 @@ int i915_sw_fence_await_active(struct i915_sw_fence
*fence,
return await_active(ref, flags, sw_await_fence, fence, fence);
}
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
void i915_active_fini(struct i915_active *ref)
{
debug_active_fini(ref);
GEM_BUG_ON(atomic_read(&ref->count));
GEM_BUG_ON(work_pending(&ref->work));
- GEM_BUG_ON(!RB_EMPTY_ROOT(&ref->tree));
mutex_destroy(&ref->mutex);
+
+ if (ref->cache)
+ kmem_cache_free(global.slab_cache, ref->cache);
}
-#endif
static inline bool is_idle_barrier(struct active_node *node, u64 idx)
{
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index 73ded3c52a04..b9e0394e2975 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -217,11 +217,7 @@ i915_active_is_idle(const struct i915_active *ref)
return !atomic_read(&ref->count);
}
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
void i915_active_fini(struct i915_active *ref);
-#else
-static inline void i915_active_fini(struct i915_active *ref) { }
-#endif
int i915_active_acquire_preallocate_barrier(struct i915_active *ref,
struct intel_engine_cs *engine);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915: Reduce locking around i915_active_acquire_preallocate_barrier()
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 spinlock for the update of the rbtree itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 03b246cb8466..d22b44f9470a 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -796,7 +796,6 @@ static struct active_node *reuse_idle_barrier(struct
i915_active *ref, u64 idx)
if (RB_EMPTY_ROOT(&ref->tree))
return NULL;
- spin_lock_irq(&ref->tree_lock);
GEM_BUG_ON(i915_active_is_idle(ref));
/*
@@ -861,11 +860,10 @@ static struct active_node *reuse_idle_barrier(struct
i915_active *ref, u64 idx)
goto match;
}
- spin_unlock_irq(&ref->tree_lock);
-
return NULL;
match:
+ spin_lock_irq(&ref->tree_lock);
rb_erase(p, &ref->tree); /* Hide from waits and sibling allocations */
if (p == &ref->cache->node)
WRITE_ONCE(ref->cache, NULL);
@@ -900,7 +898,9 @@ int i915_active_acquire_preallocate_barrier(struct
i915_active *ref,
struct llist_node *prev = first;
struct active_node *node;
+ rcu_read_lock();
node = reuse_idle_barrier(ref, idx);
+ rcu_read_unlock();
if (!node) {
node = kmem_cache_alloc(global.slab_cache, GFP_KERNEL);
if (!node) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Preallocate stashes for vma page-directories
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 for this object, even when there will be overlap.
This unfortunately can be quite expensive, especially as we have to
clear/reset the page directories and DMA pages, but it should only be
required during early phases of a workload when new objects are being
discovered, or after memory/eviction pressure when we need to rebind.
Once we reach steady state, the objects should not be moved and we no
longer need to preallocating the pages tables.
It should be noted that the lifetime for the page directories DMA is
more or less decoupled from individual fences as they will be shared
across objects across timelines.
v2: Only allocate enough PD space for the PTE we may use, we do not need
to allocate PD that will be left as scratch.
v3: Store the shift unto the first PD level to encapsulate the different
PTE counts for gen6/gen8.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 11 +--
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 40 -
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 78 +
drivers/gpu/drm/i915/gt/intel_ggtt.c | 60 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 46 ++
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 83 ---
drivers/gpu/drm/i915/i915_vma.c | 27 +++---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 60 --
drivers/gpu/drm/i915/selftests/mock_gtt.c | 22 ++---
9 files changed, 237 insertions(+), 190 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 278664f831e7..947c8aa8e13e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -32,12 +32,13 @@ static void vma_clear_pages(struct i915_vma *vma)
vma->pages = NULL;
}
-static int vma_bind(struct i915_address_space *vm,
- struct i915_vma *vma,
- enum i915_cache_level cache_level,
- u32 flags)
+static void vma_bind(struct i915_address_space *vm,
+struct i915_vm_pt_stash *stash,
+struct i915_vma *vma,
+enum i915_cache_level cache_level,
+u32 flags)
{
- return vm->vma_ops.bind_vma(vm, vma, cache_level, flags);
+ vm->vma_ops.bind_vma(vm, stash, vma, cache_level, flags);
}
static void vma_unbind(struct i915_address_space *vm, struct i915_vma *vma)
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index cdc0b9c54305..ee2e149454cb 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -177,16 +177,16 @@ static void gen6_flush_pd(struct gen6_ppgtt *ppgtt, u64
start, u64 end)
mutex_unlock(&ppgtt->flush);
}
-static int gen6_alloc_va_range(struct i915_address_space *vm,
- u64 start, u64 length)
+static void gen6_alloc_va_range(struct i915_address_space *vm,
+ struct i915_vm_pt_stash *stash,
+ u64 start, u64 length)
{
struct gen6_ppgtt *ppgtt = to_gen6_ppgtt(i915_vm_to_ppgtt(vm));
struct i915_page_directory * const pd = ppgtt->base.pd;
- struct i915_page_table *pt, *alloc = NULL;
+ struct i915_page_table *pt;
bool flush = false;
u64 from = start;
unsigned int pde;
- int ret = 0;
spin_lock(&pd->lock);
gen6_for_each_pde(pt, pd, start, length, pde) {
@@ -195,21 +195,17 @@ static int gen6_alloc_va_range(struct i915_address_space
*vm,
if (px_base(pt) == px_base(&vm->scratch[1])) {
spin_unlock(&pd->lock);
- pt = fetch_and_zero(&alloc);
- if (!pt)
- pt = alloc_pt(vm);
- if (IS_ERR(pt)) {
- ret = PTR_ERR(pt);
- goto unwind_out;
- }
+ pt = stash->pt[0];
+ GEM_BUG_ON(!pt);
fill32_px(pt, vm->scratch[0].encode);
spin_lock(&pd->lock);
if (pd->entry[pde] == &vm->scratch[1]) {
+ stash->pt[0] = pt->stash;
+ atomic_set(&pt->used, 0);
pd->entry[pde] = pt;
} else {
- alloc = pt;
pt = pd->entry[pde];
}
@@ -226,
[Intel-gfx] [PATCH 3/3] drm/i915/gt: Shrink i915_page_directory's slab bucket
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 footpoint, but the problem is excerbated by our conservative
preallocation scheme for binding VMA. As we require to allocate all
levels for each vma just in case we need to insert them upon binding,
this leads to a large multiplication factor for single page vma. By
halving the allocation we need for the page directory structure, we
halve the multipliation factor, bringing workloads that once fitted into
memory, hopefully back to fitting into memory.
We maintain the split between i915_page_directory and i915_page_table as
we only need half the allocation for the lowest, most populous, level.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 11 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 26 +++---
drivers/gpu/drm/i915/gt/intel_gtt.h | 10 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 31 +--
4 files changed, 50 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index a823d2e3c39c..8b83693f2b58 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -261,7 +261,7 @@ static void gen6_ppgtt_free_pd(struct gen6_ppgtt *ppgtt)
gen6_for_all_pdes(pt, pd, pde)
if (pt)
- free_px(&ppgtt->base.vm, pt);
+ free_pt(&ppgtt->base.vm, pt);
}
static void gen6_ppgtt_cleanup(struct i915_address_space *vm)
@@ -275,7 +275,8 @@ static void gen6_ppgtt_cleanup(struct i915_address_space
*vm)
mutex_destroy(&ppgtt->flush);
mutex_destroy(&ppgtt->pin_mutex);
- kfree(ppgtt->base.pd);
+
+ free_pd(&ppgtt->base.vm, ppgtt->base.pd);
}
static int pd_vma_set_pages(struct i915_vma *vma)
@@ -322,7 +323,7 @@ static void pd_vma_unbind(struct i915_address_space *vm,
struct i915_vma *vma)
if (!pt || atomic_read(&pt->used))
continue;
- free_px(&ppgtt->base.vm, pt);
+ free_pt(&ppgtt->base.vm, pt);
pd->entry[pde] = NULL;
}
@@ -447,7 +448,7 @@ struct i915_ppgtt *gen6_ppgtt_create(struct intel_gt *gt)
ppgtt->base.vm.alloc_pt_dma = alloc_pt_dma;
ppgtt->base.vm.pte_encode = ggtt->vm.pte_encode;
- ppgtt->base.pd = __alloc_pd(sizeof(*ppgtt->base.pd));
+ ppgtt->base.pd = __alloc_pd(I915_PDES);
if (!ppgtt->base.pd) {
err = -ENOMEM;
goto err_free;
@@ -468,7 +469,7 @@ struct i915_ppgtt *gen6_ppgtt_create(struct intel_gt *gt)
err_scratch:
free_scratch(&ppgtt->base.vm);
err_pd:
- kfree(ppgtt->base.pd);
+ free_pd(&ppgtt->base.vm, ppgtt->base.pd);
err_free:
mutex_destroy(&ppgtt->pin_mutex);
kfree(ppgtt);
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index e3afd250cd7f..3423d05068c0 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -181,7 +181,7 @@ static void __gen8_ppgtt_cleanup(struct i915_address_space
*vm,
} while (pde++, --count);
}
- free_px(vm, pd);
+ free_px(vm, &pd->pt, lvl);
}
static void gen8_ppgtt_cleanup(struct i915_address_space *vm)
@@ -248,7 +248,7 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
}
if (release_pd_entry(pd, idx, pt, scratch))
- free_px(vm, pt);
+ free_px(vm, pt, lvl);
} while (idx++, --len);
return start;
@@ -628,7 +628,7 @@ static int gen8_preallocate_top_level_pdp(struct i915_ppgtt
*ppgtt)
err = pin_pt_dma(vm, pde->pt.base);
if (err) {
i915_gem_object_put(pde->pt.base);
- kfree(pde);
+ free_pd(vm, pde);
return err;
}
@@ -648,28 +648,30 @@ gen8_alloc_top_pd(struct i915_address_space *vm)
struct i915_page_directory *pd;
int err;
- GEM_BUG_ON(count > ARRAY_SIZE(pd->entry));
+ GEM_BUG_ON(count > I915_PDES);
- pd = __alloc_pd(offsetof(typeof(*pd), entry[count]));
+ pd = __alloc_pd(count);
if (unlikely(!pd))
return ERR_PTR(-ENOMEM);
pd->pt.base = vm->alloc_pt_dma(vm, I915_GTT_PAGE_SIZE_4K);
if (IS_ERR(pd->pt.base)) {
- kfree(pd);
- return ERR_PTR(-ENOMEM);
+ err = PTR_ERR(pd->pt.base);
+ pd->pt.base = NULL;
+ goto err_pd;
}
err = pin_pt_dma(vm, pd->pt.base);
-
[Intel-gfx] [PATCH 2/3] drm/i915/gt: Switch to object allocations for page directories
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 memory, we need to ditch using plain struct page
wrappers.
In the process, we drop the WC mapping as we ended up clflushing
everything anyway due to various issues across a wider range of
platforms. Though in a future step, we need to drop the kmap_atomic
approach which suggests we need to pre-map all the pages and keep them
mapped.
v2: Verify our large scratch page is suitably DMA aligned; and manually
clear the scratch since we are allocating plain struct pages full of
prior content.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 53 ++--
drivers/gpu/drm/i915/gt/gen6_ppgtt.h | 1 +
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 89 +++---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 37 ++-
drivers/gpu/drm/i915/gt/intel_gtt.c | 300 --
drivers/gpu/drm/i915/gt/intel_gtt.h | 94 ++
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 42 ++-
.../gpu/drm/i915/gt/intel_ring_submission.c | 16 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 17 +-
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/i915_vma.c | 18 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 23 ++
drivers/gpu/drm/i915/selftests/i915_perf.c| 4 +-
drivers/gpu/drm/i915/selftests/mock_gtt.c | 4 +
18 files changed, 289 insertions(+), 420 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 5335f799b548..d0847d7896f9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -282,6 +282,7 @@ struct drm_i915_gem_object {
} userptr;
unsigned long scratch;
+ u64 encode;
void *gvt_info;
};
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 8291ede6902c..e2f3d014acb2 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -393,7 +393,7 @@ static int igt_mock_exhaust_device_supported_pages(void
*arg)
*/
for (i = 1; i < BIT(ARRAY_SIZE(page_sizes)); i++) {
- unsigned int combination = 0;
+ unsigned int combination = SZ_4K; /* Required for ppGTT */
for (j = 0; j < ARRAY_SIZE(page_sizes); j++) {
if (i & BIT(j))
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 7ffc3c751432..d176b015353f 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1748,7 +1748,7 @@ static int check_scratch_page(struct i915_gem_context
*ctx, u32 *out)
if (!vm)
return -ENODEV;
- page = vm->scratch[0].base.page;
+ page = __px_page(vm->scratch[0]);
if (!page) {
pr_err("No scratch page!\n");
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index ee2e149454cb..a823d2e3c39c 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -16,8 +16,10 @@ static inline void gen6_write_pde(const struct gen6_ppgtt
*ppgtt,
const unsigned int pde,
const struct i915_page_table *pt)
{
+ dma_addr_t addr = pt ? px_dma(pt) : px_dma(ppgtt->base.vm.scratch[1]);
+
/* Caller needs to make sure the write completes if necessary */
- iowrite32(GEN6_PDE_ADDR_ENCODE(px_dma(pt)) | GEN6_PDE_VALID,
+ iowrite32(GEN6_PDE_ADDR_ENCODE(addr) | GEN6_PDE_VALID,
ppgtt->pd_addr + pde);
}
@@ -79,7 +81,7 @@ static void gen6_ppgtt_clear_range(struct i915_address_space
*vm,
{
struct gen6_ppgtt * const ppgtt = to_gen6_ppgtt(i915_vm_to_ppgtt(vm));
const unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
- const gen6_pte_t scratch_pte = vm->scratch[0].encode;
+ const gen6_pte_t scratch_pte = vm->scratch[0]->encode;
unsigned int pde = first_entry / GEN6_PTES;
unsigned int pte = first_entry % GEN6_PTES;
unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
@@ -90,8 +92,6 @@ static void gen6_ppgtt_c
[Intel-gfx] [PATCH] drm/i915/selftests: Flush the active barriers before asserting
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 b/drivers/gpu/drm/i915/gt/selftest_context.c index 52af1cee9a94..1f4020e906a8 100644 --- a/drivers/gpu/drm/i915/gt/selftest_context.c +++ b/drivers/gpu/drm/i915/gt/selftest_context.c @@ -68,6 +68,8 @@ static int context_sync(struct intel_context *ce) } while (!err); mutex_unlock(&tl->mutex); + /* Wait for all barriers to complete (remote CPU) before we check */ + i915_active_unlock_wait(&ce->active); return err; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Copy default modparams to mock i915_device (rev4)
== 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
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/index.html
Known issues
Here are the changes found in Patchwork_18249 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
- fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1635] /
[i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-apl-guc/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/fi-apl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][5] -> [DMESG-WARN][6] ([i915#62] / [i915#92] /
[i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [FAIL][9] ([i915#1888]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-apl-guc: [DMESG-WARN][11] ([i915#1635] / [i915#1982]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-apl-guc/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- {fi-kbl-7560u}: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/fi-kbl-7560u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +3 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1888]: ht
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gt: Shrink i915_page_directory's slab bucket
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 memory utilisation, bloating the kernel footpoint, but the problem is excerbated by our conservative footprint exacerbated preallocation scheme for binding VMA. As we require to allocate all levels for each vma just in case we need to insert them upon binding, this leads to a large multiplication factor for single page vma. By halving the allocation we need for the page directory structure, we halve the multipliation factor, bringing workloads that once fitted into multiplication memory, hopefully back to fitting into memory. We maintain the split between i915_page_directory and i915_page_table as we only need half the allocation for the lowest, most populous, level. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Matthew Auld Nice find, Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Delay taking the spinlock for grabbing from the buffer pool
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 RCU, reserving taking the lock itself for
claiming the node and manipulating the list.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_gt_buffer_pool.c| 64 +--
.../drm/i915/gt/intel_gt_buffer_pool_types.h | 6 +-
2 files changed, 49 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
index 418ae184cecf..0af30238215f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
@@ -35,37 +35,51 @@ static void node_free(struct intel_gt_buffer_pool_node
*node)
{
i915_gem_object_put(node->obj);
i915_active_fini(&node->active);
- kfree(node);
+ kfree_rcu(node, rcu);
}
static void pool_free_work(struct work_struct *wrk)
{
struct intel_gt_buffer_pool *pool =
container_of(wrk, typeof(*pool), work.work);
- struct intel_gt_buffer_pool_node *node, *next;
+ struct intel_gt_buffer_pool_node *node, *stale = NULL;
unsigned long old = jiffies - HZ;
bool active = false;
- LIST_HEAD(stale);
int n;
/* Free buffers that have not been used in the past second */
- spin_lock_irq(&pool->lock);
for (n = 0; n < ARRAY_SIZE(pool->cache_list); n++) {
struct list_head *list = &pool->cache_list[n];
- /* Most recent at head; oldest at tail */
- list_for_each_entry_safe_reverse(node, next, list, link) {
- if (time_before(node->age, old))
- break;
+ if (list_empty(list))
+ continue;
+
+ if (spin_trylock_irq(&pool->lock)) {
+ struct list_head *pos;
+
+ /* Most recent at head; oldest at tail */
+ list_for_each_prev(pos, list) {
+ node = list_entry(pos, typeof(*node), link);
+ if (time_before(node->age, old))
+ break;
- list_move(&node->link, &stale);
+ node->age = 0;
+ node->free = stale;
+ stale = node;
+ }
+ if (!list_is_last(pos, list))
+ __list_del_many(pos, list);
+
+ spin_unlock_irq(&pool->lock);
}
+
active |= !list_empty(list);
}
- spin_unlock_irq(&pool->lock);
- list_for_each_entry_safe(node, next, &stale, link)
+ while ((node = stale)) {
+ stale = stale->free;
node_free(node);
+ }
if (active)
schedule_delayed_work(&pool->work,
@@ -108,9 +122,9 @@ static void pool_retire(struct i915_active *ref)
/* Return this object to the shrinker pool */
i915_gem_object_make_purgeable(node->obj);
+ node->age = jiffies ?: 1;
spin_lock_irqsave(&pool->lock, flags);
- node->age = jiffies;
- list_add(&node->link, list);
+ list_add_rcu(&node->link, list);
spin_unlock_irqrestore(&pool->lock, flags);
schedule_delayed_work(&pool->work,
@@ -151,22 +165,32 @@ intel_gt_get_buffer_pool(struct intel_gt *gt, size_t size)
struct intel_gt_buffer_pool *pool = >->buffer_pool;
struct intel_gt_buffer_pool_node *node;
struct list_head *list;
- unsigned long flags;
+ bool found = false;
int ret;
size = PAGE_ALIGN(size);
list = bucket_for_size(pool, size);
- spin_lock_irqsave(&pool->lock, flags);
- list_for_each_entry(node, list, link) {
+ rcu_read_lock();
+ list_for_each_entry_rcu(node, list, link) {
+ unsigned long flags;
+
if (node->obj->base.size < size)
continue;
- list_del(&node->link);
- break;
+
+ spin_lock_irqsave(&pool->lock, flags);
+ if (node->age) {
+ list_del_rcu(&node->link);
+ node->age = 0;
+ found = true;
+ }
+ spin_unlock_irqrestore(&pool->lock, flags);
+ if (found)
+ break;
}
- spin_unlock_irqrestore(&pool->lock, flags);
+ rcu_read_unlock();
- if (&node->link == list) {
+ if (!found) {
node = node_create(pool, size);
if (IS_ERR(node))
return node;
diff -
Re: [Intel-gfx] [PATCH 1/3] drm: Restore driver.preclose() for all to use
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, if we have a pointer into a > > drm core object from inside a driver object, that pointer needs to be > > nerfed *before* it is freed so that concurrent access (e.g. debugfs) > > does not following the dangling pointer. > > > > The legacy marker was adding in the code movement from drp_fops.c to > > drm_file.c > > I might fumble a lot, but not this one: > > commit 45c3d213a400c952ab7119f394c5293bb6877e6b > Author: Daniel Vetter > Date: Mon May 8 10:26:33 2017 +0200 > > drm: Nerf the preclose callback for modern drivers Gah, when I going through the history it looked like it appeared out of nowhere. > Also looking at the debugfs hook that has some rather adventurous > stuff going on I think, feels a bit like a kitchensink with batteries > included. If that's really all needed I'd say iterate the contexts by > first going over files, then the ctx (which arent shared anyway) and > the problem should also be gone. Or we could cut out the middlelayer and put the release under the driver control with a call to the drm_release() when the driver is ready. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 01/22] drm/i915/dg1: Initialize RAWCLK properly
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 field rather than 38 as you
> might expect.
>
> For simplicity, let's just assume that this 38.4 MHz frequency will hold
> true for other future platforms with "fake" PCH south displays and that
> the CNP-style behavior will remain for other platforms with a real PCH.
>
> Bspec: 49950
> Bspec: 49309
Reviewed-by: José Roberto de Souza
> Cc: Aditya Swarup <
> aditya.swa...@intel.com
> >
> Cc: Clinton Taylor <
> clinton.a.tay...@intel.com
> >
> Cc: Lucas De Marchi <
> lucas.demar...@intel.com
> >
> Signed-off-by: Matt Roper <
> matthew.d.ro...@intel.com
> >
> Signed-off-by: Lucas De Marchi <
> lucas.demar...@intel.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 9d6cacbdb691..7722831346ba 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2680,6 +2680,18 @@ void intel_update_cdclk(struct drm_i915_private
> *dev_priv)
> DIV_ROUND_UP(dev_priv->cdclk.hw.cdclk, 1000));
> }
>
> +static int dg1_rawclk(struct drm_i915_private *dev_priv)
> +{
> + /*
> + * DG1 always uses a 38.4 MHz rawclk. The bspec tells us
> + * "Program Numerator=2, Denominator=4, Divider=37 decimal."
> + */
> + I915_WRITE(PCH_RAWCLK_FREQ,
> +CNP_RAWCLK_DEN(4) | CNP_RAWCLK_DIV(37) | ICP_RAWCLK_NUM(2));
> +
> + return 38400;
> +}
> +
> static int cnp_rawclk(struct drm_i915_private *dev_priv)
> {
> u32 rawclk;
> @@ -2788,7 +2800,9 @@ u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
> {
> u32 freq;
>
> - if (INTEL_PCH_TYPE(dev_priv) >= PCH_CNP)
> + if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
> + freq = dg1_rawclk(dev_priv);
> + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_CNP)
> freq = cnp_rawclk(dev_priv);
> else if (HAS_PCH_SPLIT(dev_priv))
> freq = pch_rawclk(dev_priv);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: Remove disordered per-file request list for throttling (rev5)
== 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 separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Remove disordered per-file request list for throttling (rev5)
== 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 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/index.html Known issues Here are the changes found in Patchwork_18250 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-bsw-n3050: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-bsw-n3050/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-bsw-n3050/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gt_lrc: - fi-tgl-u2: [PASS][5] -> [DMESG-FAIL][6] ([i915#1233]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][9] ([i915#1888]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@i915_module_load@reload: - fi-bsw-n3050: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-bsw-n3050/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-bsw-n3050/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-bsw-kefka: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-bsw-kefka/igt@i915_pm_...@module-reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-bsw-kefka/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic: - fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html * igt@vgem_basic@setversion: - fi-tgl-y: [DMESG-WARN][17] ([i915#402]) -> [PASS][18] +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-tgl-y/igt@vgem_ba...@setversion.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-tgl-y/igt@vgem_ba...@setversion.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [DMESG-FAIL][19] ([i915#62] / [i915#95]) -> [SKIP][20] ([fdo#109271]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][22] ([i915#62] / [i915#92]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18250/fi-kbl-x1275/
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/gt: Disable preparser around xcs invalidations on tgl
== 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 : warning == Summary == $ dim checkpatch origin/drm-tip 6c95b9fa97de drm/i915/gt: Disable preparser around xcs invalidations on tgl c288f3122cdb drm/i915/selftests: Add compiler paranoia for checking HWSP values -:72: WARNING:LONG_LINE: line length of 106 exceeds 100 columns #72: FILE: drivers/gpu/drm/i915/gt/selftest_timeline.c:972: + count, tl->fence_context, tl->hwsp_offset, *tl->hwsp_seqno); total: 0 errors, 1 warnings, 0 checks, 53 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/2] drm/i915/gt: Disable preparser around xcs invalidations on tgl
== 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 : 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 mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/gt: Disable preparser around xcs invalidations on tgl
== 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 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/index.html Known issues Here are the changes found in Patchwork_18251 that come from known issues: ### IGT changes ### Issues hit * igt@gem_flink_basic@basic: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-tgl-y/igt@gem_flink_ba...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_busy@basic@flip: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-tgl-y/igt@kms_busy@ba...@flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-tgl-y/igt@kms_busy@ba...@flip.html * igt@kms_chamelium@dp-edid-read: - fi-icl-u2: [PASS][7] -> [FAIL][8] ([i915#976]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-cml-u2: [PASS][11] -> [FAIL][12] ([fdo#103375]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-cml-u2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-cml-u2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][13] ([i915#1888]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@i915_module_load@reload: - fi-bsw-n3050: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-bsw-n3050/igt@i915_module_l...@reload.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-bsw-n3050/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-bsw-kefka: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-bsw-kefka/igt@i915_pm_...@module-reload.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-bsw-kefka/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic: - fi-icl-u2: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-dp2: - fi-skl-guc: [DMESG-WARN][21] ([i915#2203]) -> [PASS][22] +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp2.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp2.html * igt@vgem_basic@setversion: - fi-tgl-y: [DMESG-WARN][23] ([i915#402]) -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8805/fi-tgl-y/igt@vgem_ba...@setversion.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18251/fi-tgl-y/igt@vgem_ba...@setversion.html Warnings * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92]) -> [DMESG-WARN][26] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
Re: [Intel-gfx] [PATCH] drm/i915/gt: Delay taking the spinlock for grabbing from the buffer pool
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 protected, we can perform the search for an > suitable node just under RCU, reserving taking the lock itself for > claiming the node and manipulating the list. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Filter wake_flags passed to default_wake_function (rev2)
== 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 tree... M drivers/gpu/drm/i915/i915_sw_fence.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Remove gen check before calling intel_rps_boost (rev2)
== 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. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Delay taking the spinlock for grabbing from the buffer pool
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 RCU, reserving taking the lock itself for
claiming the node and manipulating the list.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gt/intel_gt_buffer_pool.c| 62 +--
.../drm/i915/gt/intel_gt_buffer_pool_types.h | 6 +-
2 files changed, 48 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
index 418ae184cecf..b9c2183bb513 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
@@ -35,37 +35,51 @@ static void node_free(struct intel_gt_buffer_pool_node
*node)
{
i915_gem_object_put(node->obj);
i915_active_fini(&node->active);
- kfree(node);
+ kfree_rcu(node, rcu);
}
static void pool_free_work(struct work_struct *wrk)
{
struct intel_gt_buffer_pool *pool =
container_of(wrk, typeof(*pool), work.work);
- struct intel_gt_buffer_pool_node *node, *next;
+ struct intel_gt_buffer_pool_node *node, *stale = NULL;
unsigned long old = jiffies - HZ;
bool active = false;
- LIST_HEAD(stale);
int n;
/* Free buffers that have not been used in the past second */
- spin_lock_irq(&pool->lock);
for (n = 0; n < ARRAY_SIZE(pool->cache_list); n++) {
struct list_head *list = &pool->cache_list[n];
- /* Most recent at head; oldest at tail */
- list_for_each_entry_safe_reverse(node, next, list, link) {
- if (time_before(node->age, old))
- break;
+ if (list_empty(list))
+ continue;
+
+ if (spin_trylock_irq(&pool->lock)) {
+ struct list_head *pos;
+
+ /* Most recent at head; oldest at tail */
+ list_for_each_prev(pos, list) {
+ node = list_entry(pos, typeof(*node), link);
+ if (time_before(node->age, old))
+ break;
- list_move(&node->link, &stale);
+ node->age = 0;
+ node->free = stale;
+ stale = node;
+ }
+ if (!list_is_last(pos, list))
+ __list_del_many(pos, list);
+
+ spin_unlock_irq(&pool->lock);
}
+
active |= !list_empty(list);
}
- spin_unlock_irq(&pool->lock);
- list_for_each_entry_safe(node, next, &stale, link)
+ while ((node = stale)) {
+ stale = stale->free;
node_free(node);
+ }
if (active)
schedule_delayed_work(&pool->work,
@@ -108,9 +122,9 @@ static void pool_retire(struct i915_active *ref)
/* Return this object to the shrinker pool */
i915_gem_object_make_purgeable(node->obj);
+ WRITE_ONCE(node->age, jiffies ?: 1); /* 0 reserved for active nodes */
spin_lock_irqsave(&pool->lock, flags);
- node->age = jiffies;
- list_add(&node->link, list);
+ list_add_rcu(&node->link, list);
spin_unlock_irqrestore(&pool->lock, flags);
schedule_delayed_work(&pool->work,
@@ -151,20 +165,30 @@ intel_gt_get_buffer_pool(struct intel_gt *gt, size_t size)
struct intel_gt_buffer_pool *pool = >->buffer_pool;
struct intel_gt_buffer_pool_node *node;
struct list_head *list;
- unsigned long flags;
int ret;
size = PAGE_ALIGN(size);
list = bucket_for_size(pool, size);
- spin_lock_irqsave(&pool->lock, flags);
- list_for_each_entry(node, list, link) {
+ rcu_read_lock();
+ list_for_each_entry_rcu(node, list, link) {
+ unsigned long age;
+
if (node->obj->base.size < size)
continue;
- list_del(&node->link);
- break;
+
+ age = READ_ONCE(node->age);
+ if (!age)
+ continue;
+
+ if (cmpxchg(&node->age, age, 0) == age) {
+ spin_lock_irq(&pool->lock);
+ list_del_rcu(&node->link);
+ spin_unlock_irq(&pool->lock);
+ break;
+ }
}
- spin_unlock_irqrestore(&pool->lock, flags);
+ rcu_read_unlock();
if (&node->link == list) {
node = node_create(pool, size);
diff --git a/drivers/gpu/drm/i915/gt/in
Re: [Intel-gfx] [PATCH v5 05/16] pwm: lpss: Add pwm_lpss_prepare_enable() helper
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
> pwm_lpss_prepare_enable() helper and moves all the steps necessary for
> the not-enabled -> enabled transition there, so that we can error check
> the entire transition in a single place and only have one pm_runtime_put()
> on failure call site.
>
> While working on this I noticed that the enabled -> enabled (update
> settings) path was quite similar, so I've added an enable parameter to
> the new pwm_lpss_prepare_enable() helper, which allows using it in that
> path too.
Reviewed-by: Andy Shevchenko
But see below.
> Suggested-by: Andy Shevchenko
> Signed-off-by: Hans de Goede
> ---
> drivers/pwm/pwm-lpss.c | 45 --
> 1 file changed, 26 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index da9bc3d10104..8a136ba2a583 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -122,41 +122,48 @@ static inline void pwm_lpss_cond_enable(struct
> pwm_device *pwm, bool cond)
> pwm_lpss_write(pwm, pwm_lpss_read(pwm) | PWM_ENABLE);
> }
>
> +static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm,
> +struct pwm_device *pwm,
> +const struct pwm_state *state,
> +bool enable)
> +{
> + int ret;
> +
> + ret = pwm_lpss_is_updating(pwm);
> + if (ret)
> + return ret;
> +
> + pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period);
> + pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);
> + ret = pwm_lpss_wait_for_update(pwm);
> + if (ret)
> + return ret;
> +
> + pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == true);
> + return 0;
> +}
> +
> static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> const struct pwm_state *state)
> {
> struct pwm_lpss_chip *lpwm = to_lpwm(chip);
> - int ret;
> + int ret = 0;
We can avoid this change...
> if (state->enabled) {
> if (!pwm_is_enabled(pwm)) {
> pm_runtime_get_sync(chip->dev);
> - ret = pwm_lpss_is_updating(pwm);
> - if (ret) {
> - pm_runtime_put(chip->dev);
> - return ret;
> - }
> - pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
> state->period);
> - pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
> - ret = pwm_lpss_wait_for_update(pwm);
> - if (ret) {
> + ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
> + if (ret)
> pm_runtime_put(chip->dev);
> - return ret;
> - }
> - pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
> } else {
> - ret = pwm_lpss_is_updating(pwm);
> - if (ret)
> - return ret;
> - pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
> state->period);
> - return pwm_lpss_wait_for_update(pwm);
> + ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
...by simple return directly from here. But I admit I haven't seen the next
patch yet.
> }
> } else if (pwm_is_enabled(pwm)) {
> pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
> pm_runtime_put(chip->dev);
> }
>
> - return 0;
> + return ret;
> }
>
> static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove gen check before calling intel_rps_boost (rev2)
== 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 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/index.html Known issues Here are the changes found in Patchwork_18253 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-icl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-y/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-icl-y/igt@i915_module_l...@reload.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][7] ([i915#1888]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@gem_flink_basic@basic: - fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@gem_flink_ba...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-n3050: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-bsw-kefka: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-kefka/igt@i915_pm_...@module-reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-bsw-kefka/igt@i915_pm_...@module-reload.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][17] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][18] ([i915#62] / [i915#92]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) -> [DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html * igt@prime_vgem@basic-fence-flip: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18253/fi-kbl-x
Re: [Intel-gfx] [PATCH v5 06/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume
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 are made.
>
> This problem has been masked so far because the main consumer
> (the i915 driver) was always making duty-cycle changes on resume.
> With the conversion of the i915 driver to the atomic PWM API the
> driver now only disables/enables the PWM on suspend/resume leaving
> the output-freq and duty as is, triggering this problem.
>
> The LPSS PWM controller has a mechanism where the ctrl register value
> and the actual base-unit and on-time-div values used are latched. When
> software sets the SW_UPDATE bit then at the end of the current PWM cycle,
> the new values from the ctrl-register will be latched into the actual
> registers, and the SW_UPDATE bit will be cleared.
>
> The problem is that before this commit our suspend/resume handling
> consisted of simply saving the PWM ctrl register on suspend and
> restoring it on resume, without setting the PWM_SW_UPDATE bit.
> When the controller has lost its state over a suspend/resume and thus
> has been reset to the defaults, just restoring the register is not
> enough. We must also set the SW_UPDATE bit to tell the controller to
> latch the restored values into the actual registers.
>
> Fixing this problem is not as simple as just or-ing in the value which
> is being restored with SW_UPDATE. If the PWM was enabled before we must
> write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
> We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
> model we must do this either before or after the setting of PWM_ENABLE.
>
> All the necessary logic for doing this is already present inside
> pwm_lpss_apply(), so instead of duplicating this inside the resume
> handler, this commit makes the resume handler use pwm_lpss_apply() to
> restore the settings when necessary. This fixes the output-freq and
> duty-cycle being reset to their defaults on resume.
...
> -static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> - const struct pwm_state *state)
> +static int __pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state, bool from_resume)
> {
> struct pwm_lpss_chip *lpwm = to_lpwm(chip);
> int ret = 0;
>
> if (state->enabled) {
> if (!pwm_is_enabled(pwm)) {
> - pm_runtime_get_sync(chip->dev);
> + if (!from_resume)
> + pm_runtime_get_sync(chip->dev);
> +
> ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
> - if (ret)
> + if (ret && !from_resume)
> pm_runtime_put(chip->dev);
> } else {
> ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
> }
> } else if (pwm_is_enabled(pwm)) {
> pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
> - pm_runtime_put(chip->dev);
> +
> + if (!from_resume)
> + pm_runtime_put(chip->dev);
> }
>
> return ret;
> }
Maybe I'm too picky, but I would go even further and split apply to two versions
static int pwm_lpss_apply_on_resume(struct pwm_chip *chip, struct pwm_device
*pwm,
const struct pwm_state *state)
> {
> struct pwm_lpss_chip *lpwm = to_lpwm(chip);
>
> if (state->enabled)
> return pwm_lpss_prepare_enable(lpwm, pwm, state,
> !pwm_is_enabled(pwm));
> if (pwm_is_enabled(pwm)) {
> pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
> return 0;
> }
and another one for !from_resume.
> +static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + return __pwm_lpss_apply(chip, pwm, state, false);
> +}
...
> + ret = __pwm_lpss_apply(&lpwm->chip, pwm, &saved_state, true);
> + if (ret)
> + dev_err(dev, "Error restoring state on resume\n");
I'm wondering if it's a real error why we do not bail out?
Otherwise dev_warn() ?
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/12] drm/i915: Remove gen check before calling intel_rps_boost
== 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 intel_rps_boost
04fbf7fabc07 drm/i915: Remove requirement for holding i915_request.lock for
breadcrumbs
c12c89dac122 drm/i915/gt: Replace intel_engine_transfer_stale_breadcrumbs
712663ebd43b drm/i915/gt: Only transfer the virtual context to the new engine
if active
-:28: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#28:
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"
-:28: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 6d06779e8672 ("drm/i915: Load
balancing across a virtual engine")'
#28:
References: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine"
total: 1 errors, 1 warnings, 0 checks, 81 lines checked
7f9af8c69662 drm/i915/gt: Distinguish the virtual breadcrumbs from the irq
breadcrumbs
-:212: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#212:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 513 lines checked
912b242b2268 drm/i915/gt: Move intel_breadcrumbs_arm_irq earlier
9ed189ae62fa drm/i915/gt: Hold context/request reference while breadcrumbs are
active
5dfa302c9527 drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb
spinlock
cc2cd7609c9e drm/i915/gt: Protect context lifetime with RCU
a91359c80fc4 drm/i915/gt: Split the breadcrumb spinlock between global and
contexts
-:287: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#287: FILE: drivers/gpu/drm/i915/gt/intel_context_types.h:54:
+ spinlock_t signal_lock;
total: 0 errors, 0 warnings, 1 checks, 248 lines checked
845e59d9f06b drm/i915: Drop i915_request.lock serialisation around await_start
5c5097e2fc38 drm/i915: Drop i915_request.lock requirement for intel_rps_boost()
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/12] drm/i915: Remove gen check before calling intel_rps_boost
== 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 be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/12] drm/i915: Remove gen check before calling intel_rps_boost
== 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
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18254:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_contexts:
- {fi-tgl-dsi}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-dsi/igt@i915_selftest@live@gt_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/fi-tgl-dsi/igt@i915_selftest@live@gt_contexts.html
Known issues
Here are the changes found in Patchwork_18254 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][11] -> [DMESG-WARN][12] ([i915#2203])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
* igt@vgem_basic@debugfs:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([i915#402]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@vgem_ba...@debugfs.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/fi-tgl-y/igt@vgem_ba...@debugfs.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][15] ([i915#1888]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@basic:
- fi-tgl-y: [DMESG-WARN][17] ([i915#402]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@gem_flink_ba...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/fi-tgl-y/igt@gem_flink_ba...@basic.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-n3050: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-kefka: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18254/fi-bsw-kefka/igt@i915_pm_...@module-reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_flip@basic
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/gem: Serialise debugfs i915_gem_objects with ctx->mutex
== 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 won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Delay taking the spinlock for grabbing from the buffer pool
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 RCU, reserving taking the lock itself for
claiming the node and manipulating the list.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gt/intel_gt_buffer_pool.c| 65 +--
.../drm/i915/gt/intel_gt_buffer_pool_types.h | 6 +-
2 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
index 418ae184cecf..612aa2741e73 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
@@ -35,37 +35,54 @@ static void node_free(struct intel_gt_buffer_pool_node
*node)
{
i915_gem_object_put(node->obj);
i915_active_fini(&node->active);
- kfree(node);
+ kfree_rcu(node, rcu);
}
static void pool_free_work(struct work_struct *wrk)
{
struct intel_gt_buffer_pool *pool =
container_of(wrk, typeof(*pool), work.work);
- struct intel_gt_buffer_pool_node *node, *next;
+ struct intel_gt_buffer_pool_node *node, *stale = NULL;
unsigned long old = jiffies - HZ;
bool active = false;
- LIST_HEAD(stale);
int n;
/* Free buffers that have not been used in the past second */
- spin_lock_irq(&pool->lock);
for (n = 0; n < ARRAY_SIZE(pool->cache_list); n++) {
struct list_head *list = &pool->cache_list[n];
- /* Most recent at head; oldest at tail */
- list_for_each_entry_safe_reverse(node, next, list, link) {
- if (time_before(node->age, old))
- break;
+ if (list_empty(list))
+ continue;
+
+ if (spin_trylock_irq(&pool->lock)) {
+ struct list_head *pos;
+
+ /* Most recent at head; oldest at tail */
+ list_for_each_prev(pos, list) {
+ node = list_entry(pos, typeof(*node), link);
+ if (time_before(node->age, old))
+ break;
+
+ /* Check we are the first to claim this node */
+ if (!xchg(&node->age, 0))
+ break;
- list_move(&node->link, &stale);
+ node->free = stale;
+ stale = node;
+ }
+ if (!list_is_last(pos, list))
+ __list_del_many(pos, list);
+
+ spin_unlock_irq(&pool->lock);
}
+
active |= !list_empty(list);
}
- spin_unlock_irq(&pool->lock);
- list_for_each_entry_safe(node, next, &stale, link)
+ while ((node = stale)) {
+ stale = stale->free;
node_free(node);
+ }
if (active)
schedule_delayed_work(&pool->work,
@@ -108,9 +125,9 @@ static void pool_retire(struct i915_active *ref)
/* Return this object to the shrinker pool */
i915_gem_object_make_purgeable(node->obj);
+ WRITE_ONCE(node->age, jiffies ?: 1); /* 0 reserved for active nodes */
spin_lock_irqsave(&pool->lock, flags);
- node->age = jiffies;
- list_add(&node->link, list);
+ list_add_rcu(&node->link, list);
spin_unlock_irqrestore(&pool->lock, flags);
schedule_delayed_work(&pool->work,
@@ -151,20 +168,30 @@ intel_gt_get_buffer_pool(struct intel_gt *gt, size_t size)
struct intel_gt_buffer_pool *pool = >->buffer_pool;
struct intel_gt_buffer_pool_node *node;
struct list_head *list;
- unsigned long flags;
int ret;
size = PAGE_ALIGN(size);
list = bucket_for_size(pool, size);
- spin_lock_irqsave(&pool->lock, flags);
- list_for_each_entry(node, list, link) {
+ rcu_read_lock();
+ list_for_each_entry_rcu(node, list, link) {
+ unsigned long age;
+
if (node->obj->base.size < size)
continue;
- list_del(&node->link);
- break;
+
+ age = READ_ONCE(node->age);
+ if (!age)
+ continue;
+
+ if (cmpxchg(&node->age, age, 0) == age) {
+ spin_lock_irq(&pool->lock);
+ list_del_rcu(&node->link);
+ spin_unlock_irq(&pool->lock);
+ break;
+ }
}
- spin_unlock_irqrestore(&pool->lock, flags);
+ rcu
Re: [Intel-gfx] [PATCH v5 07/16] pwm: crc: Fix period / duty_cycle times being off by a factor of 256
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 duty-cycle steps.
>
> The pwm-crc code before this commit assumed that a clock-divider
> setting of 1 means that the PWM output is running at 6 MHZ, if that
> is true, where do these 256 duty-cycle steps come from?
>
> This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that
> seems unlikely for a PMIC which is using a silicon process optimized for
> power-switching transistors. It is way more likely that there is an 8
> bit counter for the duty cycle which acts as an extra fixed divider
> wrt the PWM output frequency.
>
> The main user of the pwm-crc driver is the i915 GPU driver which uses it
> for backlight control. Lets compare the PWM register values set by the
> video-BIOS (the GOP), assuming the extra fixed divider is present versus
> the PWM frequency specified in the Video-BIOS-Tables:
>
> Device: PWM Hz set by BIOS PWM Hz specified in VBT
> Asus T100TA 200 200
> Asus T100HA 200 200
> Lenovo Miix 2 8 23437 2
> Toshiba WT8-A 23437 2
>
> So as we can see if we assume the extra division by 256 then the register
> values set by the GOP are an exact match for the VBT values, where as
> otherwise the values would be of by a factor of 256.
>
> This commit fixes the period / duty_cycle calculations to take the
> extra division by 256 into account.
So, base clock is 6MHz, then 7 bit divisor. That's what original values
were for. On top of that there is 8-bit duty cycle control ("divide by 256"
whatever it means) with the output range 23.437kHz..183Hz.
>
> Signed-off-by: Hans de Goede
> ---
> Changes in v3:
> - Use NSEC_PER_USEC instead of adding a new (non-sensical) NSEC_PER_MHZ define
> ---
> drivers/pwm/pwm-crc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
> index 272eeb071147..c056eb9b858c 100644
> --- a/drivers/pwm/pwm-crc.c
> +++ b/drivers/pwm/pwm-crc.c
> @@ -21,8 +21,8 @@
>
> #define PWM_MAX_LEVEL0xFF
>
> -#define PWM_BASE_CLK 600 /* 6 MHz */
> -#define PWM_MAX_PERIOD_NS21333/* 46.875KHz */
> +#define PWM_BASE_CLK_MHZ 6 /* 6 MHz */
> +#define PWM_MAX_PERIOD_NS5461333 /* 183 Hz */
>
> /**
> * struct crystalcove_pwm - Crystal Cove PWM controller
> @@ -72,7 +72,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct
> pwm_device *pwm,
>
> /* changing the clk divisor, need to disable fisrt */
> crc_pwm_disable(c, pwm);
> - clk_div = PWM_BASE_CLK * period_ns / NSEC_PER_SEC;
> + clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
>
> regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
> clk_div | PWM_OUTPUT_ENABLE);
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 02/22] drm/i915/dg1: Define MOCS table for DG1
On Fri, Jul 24, 2020 at 02:38:58PM -0700, Lucas De Marchi wrote:
> DG1 has a new MOCS table. We still use the old definition of the table,
> but as for any dgfx card it doesn't contain the control_value values
> (these values don't matter as we won't program them).
>
> Bspec: 45101
>
> Cc: Daniele Ceraolo Spurio
> Cc: Rodrigo Vivi
> Signed-off-by: Lucas De Marchi
Matches the bspec
Reviewed-by: Matt Roper
I do notice that the general comment farther up the file says "The last
two entries are reserved by the hardware." --- I wonder if we should
change that to "the last few" since DG1 technically has four reserved
entries instead of just two.
Matt
> ---
> drivers/gpu/drm/i915/gt/intel_mocs.c | 39 +++-
> 1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 632e08a4592b..7217c6e2087c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -280,6 +280,39 @@ static const struct drm_i915_mocs_entry icl_mocs_table[]
> = {
> GEN11_MOCS_ENTRIES
> };
>
> +static const struct drm_i915_mocs_entry dg1_mocs_table[] = {
> + /* Error */
> + MOCS_ENTRY(0, 0, L3_0_DIRECT),
> +
> + /* UC */
> + MOCS_ENTRY(1, 0, L3_1_UC),
> +
> + /* Reserved */
> + MOCS_ENTRY(2, 0, L3_0_DIRECT),
> + MOCS_ENTRY(3, 0, L3_0_DIRECT),
> + MOCS_ENTRY(4, 0, L3_0_DIRECT),
> +
> + /* WB - L3 */
> + MOCS_ENTRY(5, 0, L3_3_WB),
> + /* WB - L3 50% */
> + MOCS_ENTRY(6, 0, L3_ESC(1) | L3_SCC(1) | L3_3_WB),
> + /* WB - L3 25% */
> + MOCS_ENTRY(7, 0, L3_ESC(1) | L3_SCC(3) | L3_3_WB),
> + /* WB - L3 12.5% */
> + MOCS_ENTRY(8, 0, L3_ESC(1) | L3_SCC(7) | L3_3_WB),
> +
> + /* HDC:L1 + L3 */
> + MOCS_ENTRY(48, 0, L3_3_WB),
> + /* HDC:L1 */
> + MOCS_ENTRY(49, 0, L3_1_UC),
> +
> + /* HW Reserved */
> + MOCS_ENTRY(60, 0, L3_1_UC),
> + MOCS_ENTRY(61, 0, L3_1_UC),
> + MOCS_ENTRY(62, 0, L3_1_UC),
> + MOCS_ENTRY(63, 0, L3_1_UC),
> +};
> +
> enum {
> HAS_GLOBAL_MOCS = BIT(0),
> HAS_ENGINE_MOCS = BIT(1),
> @@ -306,7 +339,11 @@ static unsigned int get_mocs_settings(const struct
> drm_i915_private *i915,
> {
> unsigned int flags;
>
> - if (INTEL_GEN(i915) >= 12) {
> + if (IS_DG1(i915)) {
> + table->size = ARRAY_SIZE(dg1_mocs_table);
> + table->table = dg1_mocs_table;
> + table->n_entries = GEN11_NUM_MOCS_ENTRIES;
> + } else if (INTEL_GEN(i915) >= 12) {
> table->size = ARRAY_SIZE(tgl_mocs_table);
> table->table = tgl_mocs_table;
> table->n_entries = GEN11_NUM_MOCS_ENTRIES;
> --
> 2.26.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/gem: Serialise debugfs i915_gem_objects with ctx->mutex
== 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 : success == Summary == CI Bug Log - changes from CI_DRM_8807 -> Patchwork_18255 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/index.html Known issues Here are the changes found in Patchwork_18255 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-tgl-y/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@gt_contexts: - fi-snb-2520m: [PASS][5] -> [DMESG-FAIL][6] ([i915#541]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-snb-2520m/igt@i915_selftest@live@gt_contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-snb-2520m/igt@i915_selftest@live@gt_contexts.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2: - fi-skl-guc: [PASS][9] -> [DMESG-WARN][10] ([i915#2203]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [PASS][11] -> [DMESG-WARN][12] ([i915#402]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][13] ([i915#1888]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@gem_flink_basic@basic: - fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@gem_flink_ba...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-n3050: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-bsw-kefka: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-kefka/igt@i915_pm_...@module-reload.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-bsw-kefka/igt@i915_pm_...@module-reload.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18255/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] /
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/gem: Reduce ctx->engine_mutex for reading the clone source
== 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 commit won't be checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 05/16] pwm: lpss: Add pwm_lpss_prepare_enable() helper
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. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enabled -> enabled transition there, so that we can error check
the entire transition in a single place and only have one pm_runtime_put()
on failure call site.
While working on this I noticed that the enabled -> enabled (update
settings) path was quite similar, so I've added an enable parameter to
the new pwm_lpss_prepare_enable() helper, which allows using it in that
path too.
Reviewed-by: Andy Shevchenko
But see below.
Suggested-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
drivers/pwm/pwm-lpss.c | 45 --
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index da9bc3d10104..8a136ba2a583 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -122,41 +122,48 @@ static inline void pwm_lpss_cond_enable(struct pwm_device
*pwm, bool cond)
pwm_lpss_write(pwm, pwm_lpss_read(pwm) | PWM_ENABLE);
}
+static int pwm_lpss_prepare_enable(struct pwm_lpss_chip *lpwm,
+ struct pwm_device *pwm,
+ const struct pwm_state *state,
+ bool enable)
+{
+ int ret;
+
+ ret = pwm_lpss_is_updating(pwm);
+ if (ret)
+ return ret;
+
+ pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, state->period);
+ pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == false);
+ ret = pwm_lpss_wait_for_update(pwm);
+ if (ret)
+ return ret;
+
+ pwm_lpss_cond_enable(pwm, enable && lpwm->info->bypass == true);
+ return 0;
+}
+
static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)
{
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
- int ret;
+ int ret = 0;
We can avoid this change...
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
pm_runtime_get_sync(chip->dev);
- ret = pwm_lpss_is_updating(pwm);
- if (ret) {
- pm_runtime_put(chip->dev);
- return ret;
- }
- pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
state->period);
- pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
- ret = pwm_lpss_wait_for_update(pwm);
- if (ret) {
+ ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
+ if (ret)
pm_runtime_put(chip->dev);
- return ret;
- }
- pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);
} else {
- ret = pwm_lpss_is_updating(pwm);
- if (ret)
- return ret;
- pwm_lpss_prepare(lpwm, pwm, state->duty_cycle,
state->period);
- return pwm_lpss_wait_for_update(pwm);
+ ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
...by simple return directly from here. But I admit I haven't seen the next
patch yet.
True, but I'm not a big fan of earlier returns except for errors.
Regards,
Hans
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
pm_runtime_put(chip->dev);
}
- return 0;
+ return ret;
}
static void pwm_lpss_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 06/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume
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 changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main consumer
(the i915 driver) was always making duty-cycle changes on resume.
With the conversion of the i915 driver to the atomic PWM API the
driver now only disables/enables the PWM on suspend/resume leaving
the output-freq and duty as is, triggering this problem.
The LPSS PWM controller has a mechanism where the ctrl register value
and the actual base-unit and on-time-div values used are latched. When
software sets the SW_UPDATE bit then at the end of the current PWM cycle,
the new values from the ctrl-register will be latched into the actual
registers, and the SW_UPDATE bit will be cleared.
The problem is that before this commit our suspend/resume handling
consisted of simply saving the PWM ctrl register on suspend and
restoring it on resume, without setting the PWM_SW_UPDATE bit.
When the controller has lost its state over a suspend/resume and thus
has been reset to the defaults, just restoring the register is not
enough. We must also set the SW_UPDATE bit to tell the controller to
latch the restored values into the actual registers.
Fixing this problem is not as simple as just or-ing in the value which
is being restored with SW_UPDATE. If the PWM was enabled before we must
write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
model we must do this either before or after the setting of PWM_ENABLE.
All the necessary logic for doing this is already present inside
pwm_lpss_apply(), so instead of duplicating this inside the resume
handler, this commit makes the resume handler use pwm_lpss_apply() to
restore the settings when necessary. This fixes the output-freq and
duty-cycle being reset to their defaults on resume.
...
-static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
- const struct pwm_state *state)
+static int __pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state, bool from_resume)
{
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
int ret = 0;
if (state->enabled) {
if (!pwm_is_enabled(pwm)) {
- pm_runtime_get_sync(chip->dev);
+ if (!from_resume)
+ pm_runtime_get_sync(chip->dev);
+
ret = pwm_lpss_prepare_enable(lpwm, pwm, state, true);
- if (ret)
+ if (ret && !from_resume)
pm_runtime_put(chip->dev);
} else {
ret = pwm_lpss_prepare_enable(lpwm, pwm, state, false);
}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
- pm_runtime_put(chip->dev);
+
+ if (!from_resume)
+ pm_runtime_put(chip->dev);
}
return ret;
}
Maybe I'm too picky, but I would go even further and split apply to two versions
static int pwm_lpss_apply_on_resume(struct pwm_chip *chip, struct pwm_device
*pwm,
const struct pwm_state *state)
{
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
if (state->enabled)
return pwm_lpss_prepare_enable(lpwm, pwm, state,
!pwm_is_enabled(pwm));
if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
return 0;
}
and another one for !from_resume.
It is a bit picky :) But that is actually not a bad idea, although I would write
it like this for more symmetry with the normal (not on_resume) apply version,
while at it I also renamed the function:
/*
* This is a mirror of pwm_lpss_apply() without pm_runtime reference handling
* for restoring the PWM state on resume.
*/
static int pwm_lpss_restore_state(struct pwm_chip *chip, struct pwm_device *pwm,
const struct pwm_state *state)
{
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
int ret = 0;
if (state->enabled)
ret = pwm_lpss_prepare_enable(lpwm, pwm, state,
!pwm_is_enabled(pwm));
else if (pwm_is_enabled(pwm))
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
return ret;
}
Would that work for you?
+static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
+{
+ return __pwm_lpss_apply(chip, pwm, state, false);
+}
...
+ ret = __pwm_lpss_apply(&l
Re: [Intel-gfx] [PATCH v5 07/16] pwm: crc: Fix period / duty_cycle times being off by a factor of 256
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 a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a clock-divider
setting of 1 means that the PWM output is running at 6 MHZ, if that
is true, where do these 256 duty-cycle steps come from?
This would require an internal frequency of 256 * 6 MHz = 1.5 GHz, that
seems unlikely for a PMIC which is using a silicon process optimized for
power-switching transistors. It is way more likely that there is an 8
bit counter for the duty cycle which acts as an extra fixed divider
wrt the PWM output frequency.
The main user of the pwm-crc driver is the i915 GPU driver which uses it
for backlight control. Lets compare the PWM register values set by the
video-BIOS (the GOP), assuming the extra fixed divider is present versus
the PWM frequency specified in the Video-BIOS-Tables:
Device: PWM Hz set by BIOS PWM Hz specified in VBT
Asus T100TA 200 200
Asus T100HA 200 200
Lenovo Miix 2 8 23437 2
Toshiba WT8-A 23437 2
So as we can see if we assume the extra division by 256 then the register
values set by the GOP are an exact match for the VBT values, where as
otherwise the values would be of by a factor of 256.
This commit fixes the period / duty_cycle calculations to take the
extra division by 256 into account.
So, base clock is 6MHz, then 7 bit divisor. That's what original values
were for. On top of that there is 8-bit duty cycle control ("divide by 256"
whatever it means) with the output range 23.437kHz..183Hz.
Right, so that range matches with a clock div of 1*256 (6 MHz/256 = 23437.5KHz)
to 128*256 (6 MHz/(128*256) = 183.1Hz) IOW this patch is correct.
Before this patch the code assumed a clkdiv of 1-128 (*), which leads to a
very different output frequency range.
Regards,
Hans
*) 0-127 really, that is fixed in a followup patch
Signed-off-by: Hans de Goede
---
Changes in v3:
- Use NSEC_PER_USEC instead of adding a new (non-sensical) NSEC_PER_MHZ define
---
drivers/pwm/pwm-crc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 272eeb071147..c056eb9b858c 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -21,8 +21,8 @@
#define PWM_MAX_LEVEL 0xFF
-#define PWM_BASE_CLK 600 /* 6 MHz */
-#define PWM_MAX_PERIOD_NS 21333/* 46.875KHz */
+#define PWM_BASE_CLK_MHZ 6 /* 6 MHz */
+#define PWM_MAX_PERIOD_NS 5461333 /* 183 Hz */
/**
* struct crystalcove_pwm - Crystal Cove PWM controller
@@ -72,7 +72,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct
pwm_device *pwm,
/* changing the clk divisor, need to disable fisrt */
crc_pwm_disable(c, pwm);
- clk_div = PWM_BASE_CLK * period_ns / NSEC_PER_SEC;
+ clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
regmap_write(crc_pwm->regmap, PWM0_CLK_DIV,
clk_div | PWM_OUTPUT_ENABLE);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/gem: Reduce ctx->engine_mutex for reading the clone source
== 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 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/index.html Known issues Here are the changes found in Patchwork_18256 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@gem_flink_basic@double-flink: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@gem_flink_ba...@double-flink.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-tgl-y/igt@gem_flink_ba...@double-flink.html * igt@i915_module_load@reload: - fi-bsw-n3050: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-n3050/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-bsw-n3050/igt@i915_module_l...@reload.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2: - fi-skl-guc: [PASS][9] -> [DMESG-WARN][10] ([i915#2203]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][11] ([i915#1888]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@gem_flink_basic@basic: - fi-tgl-y: [DMESG-WARN][13] ([i915#402]) -> [PASS][14] +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@gem_flink_ba...@basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-n3050: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][20] ([i915#62] / [i915#92]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18256/fi-kbl-x1275/igt@kms_cursor_leg...@ba
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915: Add a couple of missing i915_active_fini()
== 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 checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Add a couple of missing i915_active_fini()
== 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 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/index.html Known issues Here are the changes found in Patchwork_18257 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fence@basic-busy@vecs0: - fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-kefka/igt@gem_exec_fence@basic-b...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/fi-bsw-kefka/igt@gem_exec_fence@basic-b...@vecs0.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7500u: [PASS][3] -> [DMESG-WARN][4] ([i915#2203]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@vgem_basic@setversion: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@vgem_ba...@setversion.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/fi-tgl-y/igt@vgem_ba...@setversion.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][9] ([i915#1888]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@gem_flink_basic@basic: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@gem_flink_ba...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_pm_rpm@module-reload: - fi-bsw-kefka: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-kefka/igt@i915_pm_...@module-reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/fi-bsw-kefka/igt@i915_pm_...@module-reload.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-n3050: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][20] ([i915#62] / [i915#92]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-kbl-x1275: [DMESG-WARN][21] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18257/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][23] ([fdo#109271]) -> [DMESG-FAIL][24] ([i915#62]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [24]: https://intel-g
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915: Preallocate stashes for vma page-directories
== 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 checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 03/22] drm/i915/dg1: Add DG1 power wells
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 Streaming logic still remains in PW3 so still
> it needs to be enabled.
>
> DDIA, DDIB, TC1 and TC2 are the active ports on DG1.
>
> Need to keep Transcoder C and D to Pipe Power wells, this is against
> the spec but else hitting unclaimed register warnings (kept the logic
> same as TGL)
I think this paragraph is old; the bspec shows transcoders C and D in
the same power wells as pipes C and D now so this is no longer a spec
violation.
Although the bspec went through a few revisions early on, it looks like
DG1 is just a strict subset of the TGL power wells now, so there
probably isn't a need to duplicate it as a whole new table here; I think
the only thing keeping us from re-using TGL's table as-is for DG1 is the
fake "TC COLD" well that blindly makes assumptions about which outputs
are TC rather than paying attention to the real output type. I think
Aditya has some code that would fix the TCCOLD's assumptions and then we
can just point DG1 to the TGL table.
Matt
>
> Bspec: 49182
>
> Cc: Matt Roper
> Cc: Anshuman Gupta
> Signed-off-by: Uma Shankar
> Signed-off-by: Lucas De Marchi
> ---
> .../drm/i915/display/intel_display_power.c| 201 +-
> 1 file changed, 200 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 0c713e83274d..b51b82cb2398 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -2970,6 +2970,44 @@ void intel_display_power_put(struct drm_i915_private
> *dev_priv,
> BIT_ULL(POWER_DOMAIN_AUX_B) | \
> BIT_ULL(POWER_DOMAIN_INIT))
>
> +#define DG1_PW_5_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_PIPE_D) | \
> + BIT_ULL(POWER_DOMAIN_TRANSCODER_D) |\
> + BIT_ULL(POWER_DOMAIN_PIPE_D_PANEL_FITTER) | \
> + BIT_ULL(POWER_DOMAIN_INIT))
> +
> +#define DG1_PW_4_POWER_DOMAINS ( \
> + DG1_PW_5_POWER_DOMAINS |\
> + BIT_ULL(POWER_DOMAIN_PIPE_C) | \
> + BIT_ULL(POWER_DOMAIN_TRANSCODER_C) |\
> + BIT_ULL(POWER_DOMAIN_PIPE_C_PANEL_FITTER) | \
> + BIT_ULL(POWER_DOMAIN_INIT))
> +
> +#define DG1_PW_3_POWER_DOMAINS ( \
> + DG1_PW_4_POWER_DOMAINS |\
> + BIT_ULL(POWER_DOMAIN_PIPE_B) | \
> + BIT_ULL(POWER_DOMAIN_TRANSCODER_B) |\
> + BIT_ULL(POWER_DOMAIN_PIPE_B_PANEL_FITTER) | \
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_E_LANES) |\
> + BIT_ULL(POWER_DOMAIN_AUX_D) | \
> + BIT_ULL(POWER_DOMAIN_AUX_E) | \
> + BIT_ULL(POWER_DOMAIN_VGA) | \
> + BIT_ULL(POWER_DOMAIN_AUDIO) | \
> + BIT_ULL(POWER_DOMAIN_INIT))
> +
> +#define DG1_PW_2_POWER_DOMAINS ( \
> + DG1_PW_3_POWER_DOMAINS |\
> + BIT_ULL(POWER_DOMAIN_TRANSCODER_VDSC_PW2) | \
> + BIT_ULL(POWER_DOMAIN_INIT))
> +
> +#define DG1_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> + DG1_PW_3_POWER_DOMAINS |\
> + BIT_ULL(POWER_DOMAIN_MODESET) | \
> + BIT_ULL(POWER_DOMAIN_AUX_A) | \
> + BIT_ULL(POWER_DOMAIN_AUX_B) | \
> + BIT_ULL(POWER_DOMAIN_INIT))
> +
> static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
> .sync_hw = i9xx_power_well_sync_hw_noop,
> .enable = i9xx_always_on_power_well_noop,
> @@ -4474,6 +4512,165 @@ static const struct i915_power_well_desc
> rkl_power_wells[] = {
> },
> };
>
> +static const struct i915_power_well_desc dg1_power_wells[] = {
> + {
> + .name = "always-on",
> + .always_on = true,
> + .domains = POWER_DOMAIN_MASK,
> + .ops = &i9xx_always_on_power_well_ops,
> + .id = DISP_PW_ID_NONE,
> + },
> + {
> + .name = "power well 1",
> + /* Handled by the DMC firmware */
> + .always_on = true,
> + .domains = 0,
> + .ops = &hsw_power_well_ops,
> + .id = SKL_DISP_PW_1,
> + {
> + .hsw.regs = &hsw_power_well_regs,
> + .hsw.idx = ICL_PW_CTL_IDX_PW_1,
> + .hsw.has_fuses = true,
> + },
> + },
> + {
> + .name = "DC off",
> + .domains = DG1_DISPLAY_DC_OFF_POWER_DOMAINS,
> + .ops = &gen9
[Intel-gfx] ✗ Fi.CI.IGT: failure for dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
== 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 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18248_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18248_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18248_full: ### IGT changes ### Possible regressions * igt@i915_suspend@fence-restore-untiled: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/shard-skl5/igt@i915_susp...@fence-restore-untiled.html * igt@kms_flip@nonexisting-fb@c-dp1: - shard-kbl: NOTRUN -> [INCOMPLETE][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/shard-kbl1/igt@kms_flip@nonexisting...@c-dp1.html Known issues Here are the changes found in Patchwork_18248_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +9 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-skl1/igt@gem_...@in-flight-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/shard-skl7/igt@gem_...@in-flight-suspend.html * igt@kms_atomic_transition@plane-all-transition-fencing@edp-1-pipe-c: - shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([i915#2242]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-tglb5/igt@kms_atomic_transition@plane-all-transition-fenc...@edp-1-pipe-c.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/shard-tglb5/igt@kms_atomic_transition@plane-all-transition-fenc...@edp-1-pipe-c.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][7] -> [DMESG-FAIL][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-glk1/igt@kms_big...@y-tiled-64bpp-rotate-180.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_cursor_edge_walk@pipe-c-64x64-top-edge: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-glk2/igt@kms_cursor_edge_w...@pipe-c-64x64-top-edge.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/shard-glk6/igt@kms_cursor_edge_w...@pipe-c-64x64-top-edge.html * igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#72]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-glk5/igt@kms_cursor_leg...@2x-flip-vs-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/shard-glk7/igt@kms_cursor_leg...@2x-flip-vs-cursor-atomic.html * igt@kms_cursor_legacy@cursora-vs-flipb-varying-size: - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([i915#2241]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-glk7/igt@kms_cursor_leg...@cursora-vs-flipb-varying-size.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/shard-glk4/igt@kms_cursor_leg...@cursora-vs-flipb-varying-size.html * igt@kms_cursor_legacy@flip-vs-cursor-legacy: - shard-skl: [PASS][15] -> [FAIL][16] ([IGT#5]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-skl8/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/shard-skl5/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html * igt@kms_flip@2x-wf_vblank-ts-check-interruptible@ac-hdmi-a1-hdmi-a2: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#2122]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-glk1/igt@kms_flip@2x-wf_vblank-ts-check-interrupti...@ac-hdmi-a1-hdmi-a2.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/shard-glk3/igt@kms_flip@2x-wf_vblank-ts-check-interrupti...@ac-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#2122]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18248/shard-skl3/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i91
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Preallocate stashes for vma page-directories
== 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 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/index.html Known issues Here are the changes found in Patchwork_18258 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-tgl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_selftest@live@gem_contexts: - fi-tgl-u2: [PASS][3] -> [INCOMPLETE][4] ([i915#2045]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html * igt@kms_flip@basic-flip-vs-modeset@d-edp1: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@kms_flip@basic-flip-vs-mode...@d-edp1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-tgl-y/igt@kms_flip@basic-flip-vs-mode...@d-edp1.html * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][9] ([i915#1888]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-n3050: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html * igt@vgem_basic@dmabuf-fence-before: - fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][17] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][18] ([i915#62] / [i915#92]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-kbl-x1275: [DMESG-WARN][19] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html * igt@i915_pm_rpm@module-reload: - fi-skl-6700k2: [DMESG-WARN][21] ([i915#2203]) -> [INCOMPLETE][22] ([i915#151]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-skl-6700k2/igt@i915_pm_...@module-reload.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-skl-6700k2/igt@i915_pm_...@module-reload.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95]) +8 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18258/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.htm
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/selftests: Flush the active barriers before asserting
== 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. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Flush the active barriers before asserting
== 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 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/index.html Known issues Here are the changes found in Patchwork_18259 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [PASS][1] -> [FAIL][2] ([i915#1888]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@i915_pm_rpm@module-reload: - fi-bsw-n3050: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-n3050/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-bsw-n3050/igt@i915_pm_...@module-reload.html - fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-byt-j1900/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-byt-j1900/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gem_contexts: - fi-tgl-u2: [PASS][7] -> [INCOMPLETE][8] ([i915#2045]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html * igt@kms_busy@basic@flip: - fi-kbl-x1275: [PASS][9] -> [DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic: - fi-icl-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2: - fi-skl-guc: [PASS][13] -> [DMESG-WARN][14] ([i915#2203]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html * igt@prime_vgem@basic-write: - fi-tgl-y: [PASS][15] -> [DMESG-WARN][16] ([i915#402]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@prime_v...@basic-write.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-tgl-y/igt@prime_v...@basic-write.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][17] ([i915#1888]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@gem_flink_basic@basic: - fi-tgl-y: [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@gem_flink_ba...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-n3050: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-bsw-kefka: [DMESG-WARN][23] ([i915#1982]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-kefka/igt@i915_pm_...@module-reload.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-bsw-kefka/igt@i915_pm_...@module-reload.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][25] ([i915#1982]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18259/fi-
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Delay taking the spinlock for grabbing from the buffer pool (rev5)
== 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 checked separately. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Copy default modparams to mock i915_device (rev4)
== 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 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18249_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18249_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_18249_full: ### IGT changes ### Possible regressions * igt@gem_eio@kms: - shard-glk: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-glk7/igt@gem_...@kms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/shard-glk1/igt@gem_...@kms.html * igt@kms_flip@nonexisting-fb@c-dp1: - shard-kbl: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/shard-kbl1/igt@kms_flip@nonexisting...@c-dp1.html Known issues Here are the changes found in Patchwork_18249_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_atomic_transition@plane-all-transition-fencing@edp-1-pipe-c: - shard-tglb: [PASS][4] -> [INCOMPLETE][5] ([i915#2242]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-tglb5/igt@kms_atomic_transition@plane-all-transition-fenc...@edp-1-pipe-c.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/shard-tglb5/igt@kms_atomic_transition@plane-all-transition-fenc...@edp-1-pipe-c.html * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - shard-glk: [PASS][6] -> [DMESG-FAIL][7] ([i915#118] / [i915#95]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-glk5/igt@kms_big...@x-tiled-64bpp-rotate-0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html * igt@kms_big_fb@y-tiled-16bpp-rotate-0: - shard-skl: [PASS][8] -> [DMESG-WARN][9] ([i915#1982]) +10 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-skl8/igt@kms_big...@y-tiled-16bpp-rotate-0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/shard-skl6/igt@kms_big...@y-tiled-16bpp-rotate-0.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][10] -> [DMESG-WARN][11] ([i915#1635] / [i915#180]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-apl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/shard-apl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_edge_walk@pipe-c-64x64-top-edge: - shard-glk: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-glk2/igt@kms_cursor_edge_w...@pipe-c-64x64-top-edge.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/shard-glk2/igt@kms_cursor_edge_w...@pipe-c-64x64-top-edge.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][14] -> [FAIL][15] ([i915#79]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/shard-skl1/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-kbl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) +11 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-kbl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/shard-kbl7/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html * igt@kms_flip@flip-vs-suspend@b-edp1: - shard-skl: [PASS][18] -> [INCOMPLETE][19] ([i915#198]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-skl8/igt@kms_flip@flip-vs-susp...@b-edp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/shard-skl9/igt@kms_flip@flip-vs-susp...@b-edp1.html * igt@kms_flip@nonexisting-fb-interruptible@a-edp1: - shard-iclb: [PASS][20] -> [INCOMPLETE][21] ([i915#2240]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8804/shard-iclb4/igt@kms_flip@nonexisting-fb-interrupti...@a-edp1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18249/shard-iclb4/igt@kms_flip@nonexisting-fb-interrupti...@a-edp1.html * igt@kms_flip_tiling@flip-yf-tiled: - shard-
Re: [Intel-gfx] [PATCH v5 04/22] drm/i915/dg1: Increase mmio size to 4MB
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 Marchi
We may want to provide "Bspec: 53616" as a reference. Technically the
overall space reserved for MMIO is 8MB, but that page helps detail the
layout. The registers we actually use top out out 28_ I believe, so
a 4MB range should be sufficient.
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index f5edee17902a..8f9c82aa7338 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1701,11 +1701,15 @@ static int uncore_mmio_setup(struct intel_uncore
> *uncore)
>* clobbering the GTT which we want ioremap_wc instead. Fortunately,
>* the register BAR remains the same size for all the earlier
>* generations up to Ironlake.
> + * For dgfx chips register range is expanded to 4MB.
>*/
> if (INTEL_GEN(i915) < 5)
> mmio_size = 512 * 1024;
> + else if (IS_DGFX(i915))
> + mmio_size = 4 * 1024 * 1024;
> else
> mmio_size = 2 * 1024 * 1024;
> +
> uncore->regs = pci_iomap(pdev, mmio_bar, mmio_size);
> if (uncore->regs == NULL) {
> drm_err(&i915->drm, "failed to map registers\n");
> --
> 2.26.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 06/22] drm/i915/dg1: Add DPLL macros for DG1
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 the commit message to avoid
confusion (i.e., DDI-TC1 and DDI-TC2 instead of DDIC/DDID).
Aside from that,
Reviewed-by: Matt Roper
>
> 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
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 17 +
> drivers/gpu/drm/i915/i915_reg.h | 17 -
> 2 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> index 5d9a2bc371e7..205542fb8dc7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
> @@ -154,6 +154,23 @@ enum intel_dpll_id {
>* @DPLL_ID_TGL_MGPLL6: TGL TC PLL port 6 (TC6)
>*/
> DPLL_ID_TGL_MGPLL6 = 8,
> +
> + /**
> + * @DPLL_ID_DG1_DPLL0: DG1 combo PHY DPLL0
> + */
> + DPLL_ID_DG1_DPLL0 = 0,
> + /**
> + * @DPLL_ID_DG1_DPLL1: DG1 combo PHY DPLL1
> + */
> + DPLL_ID_DG1_DPLL1 = 1,
> + /**
> + * @DPLL_ID_DG1_DPLL2: DG1 combo PHY DPLL2
> + */
> + DPLL_ID_DG1_DPLL2 = 2,
> + /**
> + * @DPLL_ID_DG1_DPLL3: DG1 combo PHY DPLL3
> + */
> + DPLL_ID_DG1_DPLL3 = 3,
> };
>
> #define I915_NUM_PLLS 9
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3767b32127da..986e31af7763 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -242,7 +242,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> #define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
> #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
> -#define _MMIO_PLL3(pll, a, b, c) _MMIO(_PICK(pll, a, b, c))
> +#define _MMIO_PLL3(pll, ...) _MMIO(_PICK(pll, __VA_ARGS__))
> +
>
> /*
> * Device info offset array based helpers for groups of registers with
> unevenly
> @@ -10547,6 +10548,20 @@ enum skl_power_gate {
> #define RKL_DPLL_CFGCR1(pll) _MMIO_PLL(pll, _TGL_DPLL0_CFGCR1, \
> _TGL_DPLL1_CFGCR1)
>
> +#define _DG1_DPLL2_CFGCR00x16C284
> +#define _DG1_DPLL3_CFGCR00x16C28C
> +#define DG1_DPLL_CFGCR0(pll) _MMIO_PLL3(pll, _TGL_DPLL0_CFGCR0, \
> +_TGL_DPLL1_CFGCR0, \
> +_DG1_DPLL2_CFGCR0, \
> +_DG1_DPLL3_CFGCR0)
> +
> +#define _DG1_DPLL2_CFGCR1 0x16C288
> +#define _DG1_DPLL3_CFGCR1 0x16C290
> +#define DG1_DPLL_CFGCR1(pll)_MMIO_PLL3(pll, _TGL_DPLL0_CFGCR1, \
> +_TGL_DPLL1_CFGCR1, \
> +_DG1_DPLL2_CFGCR1, \
> +_DG1_DPLL3_CFGCR1)
> +
> #define _DKL_PHY1_BASE 0x168000
> #define _DKL_PHY2_BASE 0x169000
> #define _DKL_PHY3_BASE 0x16A000
> --
> 2.26.2
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Delay taking the spinlock for grabbing from the buffer pool (rev5)
== 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 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/index.html Known issues Here are the changes found in Patchwork_18260 that come from known issues: ### IGT changes ### Issues hit * igt@gem_flink_basic@bad-open: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@gem_flink_ba...@bad-open.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-tgl-y/igt@gem_flink_ba...@bad-open.html * igt@i915_module_load@reload: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-tgl-y/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-byt-j1900: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-bsw-kefka: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2: - fi-skl-guc: [PASS][11] -> [DMESG-WARN][12] ([i915#2203]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][13] ([i915#1888]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@gem_flink_basic@basic: - fi-tgl-y: [DMESG-WARN][15] ([i915#402]) -> [PASS][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-tgl-y/igt@gem_flink_ba...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_module_load@reload: - fi-bsw-kefka: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-kefka/igt@i915_module_l...@reload.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-bsw-kefka/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-n3050: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-bsw-n3050/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8807/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18260/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-kbl-x1275: [DMESG-WAR
