Re: [Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Friday, August 16, 2019 3:08 PM
> To: Tang, CQ
> Cc: Intel Graphics Development ; Chris
> Wilson ; Ursulin, Tvrtko
> ; Joonas Lahtinen
> ; Vetter, Daniel
> Subject: Re: [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on
> its head
>
> On Fri, Aug 16, 2019 at 9:23 PM Tang, CQ wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> > > Sent: Friday, August 16, 2019 11:24 AM
> > > To: Intel Graphics Development
> > > Cc: Daniel Vetter ; Chris Wilson
> > > ; Tang, CQ ; Ursulin,
> > > Tvrtko ; Joonas Lahtinen
> > > ; Vetter, Daniel
> > >
> > > Subject: [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations
> > > on its head
> > >
> > > The trouble with having a plain nesting flag for locks which do not
> > > naturally nest (unlike block devices and their partitions, which is
> > > the original motivation for nesting levels) is that lockdep will
> > > never spot a true deadlock if you screw up.
> > >
> > > This patch is an attempt at trying better, by highlighting a bit
> > > more the actual nature of the nesting that's going on. Essentially
> > > we have two kinds of
> > > objects:
> > >
> > > - objects without pages allocated, which cannot be on any lru and are
> > > hence inaccessible to the shrinker.
> > >
> > > - objects which have pages allocated, which are on an lru, and which
> > > the shrinker can decide to throw out.
> > >
> > > For the former type of object, memory allcoations while holding
> > > obj->mm.lock are permissible. For the latter they are not. And
> > > get/put_pages transitions between the two types of objects.
> > >
> > > This is still not entirely fool-proof since the rules might chance.
> > > But as long as we run such a code ever at runtime lockdep should be
> > > able to observe the inconsistency and complain (like with any other
> > > lockdep class that we've split up in multiple classes). But there are a
> > > few
> clear benefits:
> > >
> > > - We can drop the nesting flag parameter from
> > > __i915_gem_object_put_pages, because that function by definition is
> > > never going allocate memory, and calling it on an object which
> > > doesn't have its pages allocated would be a bug.
> > >
> > > - We strictly catch more bugs, since there's not only one place in the
> > > entire tree which is annotated with the special class. All the
> > > other places that had explicit lockdep nesting annotations we're now
> > > going to leave up to lockdep again.
> > >
> > > - Specifically this catches stuff like calling get_pages from
> > > put_pages (which isn't really a good idea, if we can call put_pages
> > > so could the shrinker). I've seen patches do exactly that.
> > >
> > > Of course I fully expect CI will show me for the fool I am with this
> > > one here :-)
> > >
> > > v2: There can only be one (lockdep only has a cache for the first
> > > subclass, not for deeper ones, and we don't want to make these locks
> > > even slower). Still separate enums for better documentation.
> > >
> > > Real fix: don forget about phys objs and pin_map(), and fix the
> > > shrinker to have the right annotations ... silly me.
> > >
> > > v3: Forgot usertptr too ...
> > >
> > > v4: Improve comment for pages_pin_count, drop the IMPORTANT
> comment
> > > and instead prime lockdep (Chris).
> > >
> > > Cc: Chris Wilson
> > > Cc: "Tang, CQ"
> > > Cc: Tvrtko Ursulin
> > > Cc: Joonas Lahtinen
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_object.c | 13 -
> > > drivers/gpu/drm/i915/gem/i915_gem_object.h | 16
> +---
> > > drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 6 +-
> > > drivers/gpu/drm/i915/gem/i915_gem_pages.c| 9 -
> > > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
> > > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 5 ++---
> > > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 ++--
> > > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++--
> > > 8 files changed, 45 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > > index 3929c3a6b281..d01258b175f5 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > > @@ -22,6 +22,8 @@
> > > *
> > > */
> > >
> > > +#include
> > > +
> > > #include "display/intel_frontbuffer.h"
> > > #include "gt/intel_gt.h"
> > > #include "i915_drv.h"
> > > @@ -61,6 +63,15 @@ void i915_gem_object_init(struct
> > > drm_i915_gem_object *obj, {
> > > mutex_init(>mm.lock);
> > >
> > > + if (IS_ENABLED(CONFIG_LOCKDEP)) {
> > > + mutex_lock_nested(>mm.lock,
> > > I915_MM_GET_PAGES);
> > > + fs_reclaim_acquire(GFP_KERNEL);
> > > +
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Only emit the 'send bug report' once for a GPU hang
== Series Details == Series: drm/i915: Only emit the 'send bug report' once for a GPU hang URL : https://patchwork.freedesktop.org/series/65301/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6718_full -> Patchwork_14052_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14052_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14052_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_14052_full: ### IGT changes ### Possible regressions * igt@kms_vblank@pipe-a-ts-continuation-dpms-rpm: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/shard-skl3/igt@kms_vbl...@pipe-a-ts-continuation-dpms-rpm.html Known issues Here are the changes found in Patchwork_14052_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][2] -> [SKIP][3] ([fdo#111325]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb8/igt@gem_exec_sched...@preemptive-hang-bsd.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/shard-iclb2/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_workarounds@suspend-resume-fd: - shard-skl: [PASS][4] -> [INCOMPLETE][5] ([fdo#104108]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-skl8/igt@gem_workarou...@suspend-resume-fd.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/shard-skl8/igt@gem_workarou...@suspend-resume-fd.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][6] -> [FAIL][7] ([fdo#105767]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [PASS][8] -> [FAIL][9] ([fdo#105363]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-glk2/igt@kms_f...@flip-vs-expired-vblank.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/shard-glk3/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-snb: [PASS][10] -> [DMESG-WARN][11] ([fdo#102365]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-snb1/igt@kms_f...@flip-vs-suspend-interruptible.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/shard-snb2/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-badstride: - shard-iclb: [PASS][12] -> [FAIL][13] ([fdo#103167]) +7 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb8/igt@kms_frontbuffer_track...@fbc-badstride.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/shard-iclb2/igt@kms_frontbuffer_track...@fbc-badstride.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#109441]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/shard-iclb8/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-apl: [PASS][16] -> [FAIL][17] ([fdo#99912]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-apl1/igt@kms_setm...@basic.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/shard-apl2/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-apl: [PASS][18] -> [DMESG-WARN][19] ([fdo#108566]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-apl2/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/shard-apl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-kbl: [PASS][20] -> [INCOMPLETE][21] ([fdo#103665]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-kbl7/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/shard-kbl3/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html * igt@prime_busy@wait-hang-vebox: - shard-apl: [PASS][22] -> [INCOMPLETE][23]
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Sanitize PHY state during display core uninit
== Series Details == Series: drm/i915: Sanitize PHY state during display core uninit URL : https://patchwork.freedesktop.org/series/65298/ State : success == Summary == CI Bug Log - changes from CI_DRM_6718_full -> Patchwork_14050_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14050_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-snb: [PASS][1] -> [FAIL][2] ([fdo#109661]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-snb6/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb3/igt@gem_exec_as...@concurrent-writes-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-iclb2/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb4/igt@gem_exec_balan...@smoke.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-iclb3/igt@gem_exec_balan...@smoke.html * igt@gem_exec_flush@basic-wb-prw-default: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([fdo#103927]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-apl1/igt@gem_exec_fl...@basic-wb-prw-default.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-apl6/igt@gem_exec_fl...@basic-wb-prw-default.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-apl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-glk8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-glk2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-hsw: [PASS][15] -> [INCOMPLETE][16] ([fdo#103540]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-hsw2/igt@kms_f...@flip-vs-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-hsw5/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb3/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-iclb4/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#108341]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb3/igt@kms_psr@no_drrs.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-iclb8/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@prime_busy@after-bsd2: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109276]) +18 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb4/igt@prime_b...@after-bsd2.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/shard-iclb3/igt@prime_b...@after-bsd2.html Possible fixes * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [SKIP][25] ([fdo#111325]) -> [PASS][26] +2 similar issues [25]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gtt: Fold gen8 insertions into one (rev2)
== Series Details == Series: drm/i915/gtt: Fold gen8 insertions into one (rev2) URL : https://patchwork.freedesktop.org/series/65258/ State : success == Summary == CI Bug Log - changes from CI_DRM_6718_full -> Patchwork_14049_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14049_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@q-smoketest-bsd1: - shard-apl: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-apl7/igt@gem_ctx_sha...@q-smoketest-bsd1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/shard-apl4/igt@gem_ctx_sha...@q-smoketest-bsd1.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb3/igt@gem_exec_as...@concurrent-writes-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/shard-iclb4/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb4/igt@gem_exec_balan...@smoke.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/shard-iclb5/igt@gem_exec_balan...@smoke.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([fdo#108686]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-glk3/igt@gem_tiled_swapp...@non-threaded.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/shard-glk5/igt@gem_tiled_swapp...@non-threaded.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#110741]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_flip@2x-flip-vs-suspend: - shard-hsw: [PASS][11] -> [INCOMPLETE][12] ([fdo#103540]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-hsw1/igt@kms_f...@2x-flip-vs-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/shard-hsw4/igt@kms_f...@2x-flip-vs-suspend.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-kbl: [PASS][13] -> [FAIL][14] ([fdo#105363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-kbl6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/shard-kbl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +6 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_frontbuffer_tracking@fbcpsr-suspend: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#104108] / [fdo#106978]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-skl7/igt@kms_frontbuffer_track...@fbcpsr-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/shard-skl2/igt@kms_frontbuffer_track...@fbcpsr-suspend.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-apl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_scaling@pipe-c-scaler-with-clipping-clamping: - shard-iclb: [PASS][21] -> [INCOMPLETE][22] ([fdo#107713] / [fdo#110041]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb5/igt@kms_plane_scal...@pipe-c-scaler-with-clipping-clamping.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/shard-iclb7/igt@kms_plane_scal...@pipe-c-scaler-with-clipping-clamping.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen11: Allow usage of all GPIO pins (rev4)
== Series Details ==
Series: drm/i915/gen11: Allow usage of all GPIO pins (rev4)
URL : https://patchwork.freedesktop.org/series/65261/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6723 -> Patchwork_14067
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14067/
Known issues
Here are the changes found in Patchwork_14067 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6723/fi-blb-e6850/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14067/fi-blb-e6850/igt@i915_module_l...@reload.html
Possible fixes
* igt@gem_exec_fence@basic-busy-default:
- fi-icl-u3: [DMESG-WARN][3] ([fdo#107724]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6723/fi-icl-u3/igt@gem_exec_fe...@basic-busy-default.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14067/fi-icl-u3/igt@gem_exec_fe...@basic-busy-default.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-hsw-4770:[SKIP][5] ([fdo#109271]) -> [PASS][6] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6723/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14067/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic-flip-c:
- {fi-icl-u4}:[DMESG-WARN][7] ([fdo#105602]) -> [PASS][8] +5
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6723/fi-icl-u4/igt@kms_b...@basic-flip-c.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14067/fi-icl-u4/igt@kms_b...@basic-flip-c.html
* igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][9] ([fdo#111045]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6723/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14067/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][11] ([fdo#109483]) -> [FAIL][12] ([fdo#111407])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6723/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14067/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (54 -> 45)
--
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050
fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6723 -> Patchwork_14067
CI-20190529: 20190529
CI_DRM_6723: 3f85829ae2a124e54e39977748f2c85cd4be6b34 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14067: 058bf5a4651d0a4d9b32d1cc8aed27ac38544ea2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
058bf5a4651d drm/i915/gen11: Allow usage of all GPIO pins
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14067/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux Kernel 5.2.8 (uvc or i915? <<<)
Kernel is the dmesg from the kernel I run on a daily basis. On 8/16/19, Laurent Pinchart wrote: > Hi Randy, > > On Thu, Aug 15, 2019 at 08:10:03PM -0700, Randy Dunlap wrote: >> [adding mailing lists etc. with Nathaniel's test info] >> >> On 8/15/19 7:21 PM, Nathaniel Russell wrote: >> > Well i surpressed the uvcvideo driver and you are right Randy it >> > definitely is not the uvcvideo driver. There is something going on in >> > the i915 driver. >> > >> > On 8/15/19, Randy Dunlap wrote: >> >> On 8/15/19 6:15 PM, Nathaniel Russell wrote: >> >>> I would really like help with the kernel error with my uvcvideo >> >>> driver. >> >> >> >> Hi again. >> >> >> >> What makes you think that the problem is related to the uvcvideo >> >> driver? >> >> Does some previous kernel version work correctly? If so, what >> >> version(s)? >> >> >> >> >> >> Does this warning message only happen when the uvcvideo driver is >> >> being >> >> loaded? >> >> Can you suppress loading of the uvcvideo driver to find out? >> >> >> >> Most of the problems/errors/warnings that I see are related to the >> >> i915 >> >> driver: >> >> >> >> [ 13.032341] timed out waiting for port C ready: got 0x20, expected >> >> 0xe0 >> >> [ 13.032872] WARNING: CPU: 1 PID: 239 at >> >> drivers/gpu/drm/i915/intel_display.c:1597 >> >> vlv_wait_port_ready+0x99/0xe0 >> >> [i915] >> >> [ 13.033632] RIP: 0010:vlv_wait_port_ready+0x99/0xe0 [i915] >> >> >> >> although there are a few uvcvideo warnings: >> >> [ 13.039305] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was >> >> not >> >> initialized! >> >> [ 13.039318] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was >> >> not >> >> initialized! >> >> [ 13.039330] uvcvideo 1-5:1.0: Entity type for entity Processing 2 >> >> was not >> >> initialized! >> >> [ 13.039339] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was >> >> not >> >> initialized! >> >> >> >> Laurent, do you see any uvc issues here? Any ideas/suggestions? > > No, uvcvideo seems completely reunlated. > >> >> @intel-gfx: any ideas about what is going on here with the i915 >> >> driver? >> >> >> >> Original message to lkml: >> >> https://lore.kernel.org/lkml/CAONH+Jm-O6=dq+k2n5pntnmg2sq1kcvnfluwevh6w82opef...@mail.gmail.com/T/#u >> >> >> >> Previous message for 5.1.21 kernel: >> >> https://lore.kernel.org/lkml/CAONH+JkTFujY9vEyNNuem+9rJ2qBKkf-PbKk9=DBSVEp6kW=y...@mail.gmail.com/ > > -- > Regards, > > Laurent Pinchart > kernel Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915/gen11: Allow usage of all GPIO pins
Our pin mapping tables for ICP and MCC currently only list the standard
GPIO pins used for various output ports. Even through ICP's standard
pin usage only utilizes pins 1, 2, and 9-12, and MCC's standard pin
usage only uses pins 1, 2, and 9, these platforms do still have GPIO
registers to address pins in the range 1-3 and 9-14. OEM's may remap
GPIO usage in non-standard ways (and provide the actual mapping via VBT
settings), so we shouldn't exclude pins on these platforms just because
they aren't part of the standard mappings.
TGP's standard pin tables contains all the possible pins, so let's
rename them to "icp" and use them for all PCH >= PCH_ICP. This will
prevent intel_gmbus_is_valid_pin from rejecting non-standard pin usage
that an OEM specifies via the VBT.
Note that this will cause pin 9 to be labeled as "tc1" instead of "dpc"
in debug messages on platforms with the MCC PCH, but that may actually
help avoid confusion since the text strings will now be the same on all
gen11+ platforms instead of being different on just EHL.
v2: Drop now-unused MCC_DDC_BUS_DDI_* names.
v3: We want to compare against INTEL_PCH_TYPE, not INTEL_PCH_ID.
Bspec: 8417
Cc: José Roberto de Souza
Cc: Lucas De Marchi
Cc: Vivek Kasireddy
Cc: Jani Nikula
Signed-off-by: Matt Roper
Reviewed-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_bios.c | 23 +---
drivers/gpu/drm/i915/display/intel_gmbus.c| 27 ++-
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 3 ---
3 files changed, 3 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index b416b394b641..efb39f350b19 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1341,21 +1341,6 @@ static const u8 cnp_ddc_pin_map[] = {
};
static const u8 icp_ddc_pin_map[] = {
- [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
- [ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
- [ICL_DDC_BUS_PORT_1] = GMBUS_PIN_9_TC1_ICP,
- [ICL_DDC_BUS_PORT_2] = GMBUS_PIN_10_TC2_ICP,
- [ICL_DDC_BUS_PORT_3] = GMBUS_PIN_11_TC3_ICP,
- [ICL_DDC_BUS_PORT_4] = GMBUS_PIN_12_TC4_ICP,
-};
-
-static const u8 mcc_ddc_pin_map[] = {
- [MCC_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
- [MCC_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
- [MCC_DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
-};
-
-static const u8 tgp_ddc_pin_map[] = {
[ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
[ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
[TGL_DDC_BUS_DDI_C] = GMBUS_PIN_3_BXT,
@@ -1372,13 +1357,7 @@ static u8 map_ddc_pin(struct drm_i915_private *dev_priv,
u8 vbt_pin)
const u8 *ddc_pin_map;
int n_entries;
- if (HAS_PCH_TGP(dev_priv)) {
- ddc_pin_map = tgp_ddc_pin_map;
- n_entries = ARRAY_SIZE(tgp_ddc_pin_map);
- } else if (HAS_PCH_MCC(dev_priv)) {
- ddc_pin_map = mcc_ddc_pin_map;
- n_entries = ARRAY_SIZE(mcc_ddc_pin_map);
- } else if (HAS_PCH_ICP(dev_priv)) {
+ if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP) {
ddc_pin_map = icp_ddc_pin_map;
n_entries = ARRAY_SIZE(icp_ddc_pin_map);
} else if (HAS_PCH_CNP(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index 1e27b18aa3fc..d6775a005726 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -80,21 +80,6 @@ static const struct gmbus_pin gmbus_pins_cnp[] = {
};
static const struct gmbus_pin gmbus_pins_icp[] = {
- [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
- [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
- [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
- [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOK },
- [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOL },
- [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOM },
-};
-
-static const struct gmbus_pin gmbus_pins_mcc[] = {
- [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
- [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
- [GMBUS_PIN_9_TC1_ICP] = { "dpc", GPIOJ },
-};
-
-static const struct gmbus_pin gmbus_pins_tgp[] = {
[GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
[GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
[GMBUS_PIN_3_BXT] = { "dpc", GPIOD },
@@ -110,11 +95,7 @@ static const struct gmbus_pin gmbus_pins_tgp[] = {
static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
unsigned int pin)
{
- if (HAS_PCH_TGP(dev_priv))
- return _pins_tgp[pin];
- else if (HAS_PCH_MCC(dev_priv))
- return _pins_mcc[pin];
- else if (HAS_PCH_ICP(dev_priv))
+ if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
return _pins_icp[pin];
else if (HAS_PCH_CNP(dev_priv))
return _pins_cnp[pin];
@@ -133,11 +114,7 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private
Re: [Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Friday, August 16, 2019 3:03 PM
> To: Chris Wilson
> Cc: Intel Graphics Development ; Tang, CQ
> ; Ursulin, Tvrtko ; Joonas
> Lahtinen ; Vetter, Daniel
>
> Subject: Re: [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on
> its head
>
> On Fri, Aug 16, 2019 at 8:46 PM Chris Wilson
> wrote:
> >
> > Quoting Daniel Vetter (2019-08-16 19:23:36)
> > > The trouble with having a plain nesting flag for locks which do not
> > > naturally nest (unlike block devices and their partitions, which is
> > > the original motivation for nesting levels) is that lockdep will
> > > never spot a true deadlock if you screw up.
> > >
> > > This patch is an attempt at trying better, by highlighting a bit
> > > more the actual nature of the nesting that's going on. Essentially
> > > we have two kinds of objects:
> > >
> > > - objects without pages allocated, which cannot be on any lru and are
> > > hence inaccessible to the shrinker.
> > >
> > > - objects which have pages allocated, which are on an lru, and which
> > > the shrinker can decide to throw out.
> > >
> > > For the former type of object, memory allcoations while holding
> > > obj->mm.lock are permissible. For the latter they are not. And
> > > get/put_pages transitions between the two types of objects.
> > >
> > > This is still not entirely fool-proof since the rules might chance.
> > > But as long as we run such a code ever at runtime lockdep should be
> > > able to observe the inconsistency and complain (like with any other
> > > lockdep class that we've split up in multiple classes). But there
> > > are a few clear benefits:
> > >
> > > - We can drop the nesting flag parameter from
> > > __i915_gem_object_put_pages, because that function by definition is
> > > never going allocate memory, and calling it on an object which
> > > doesn't have its pages allocated would be a bug.
> > >
> > > - We strictly catch more bugs, since there's not only one place in the
> > > entire tree which is annotated with the special class. All the
> > > other places that had explicit lockdep nesting annotations we're now
> > > going to leave up to lockdep again.
> > >
> > > - Specifically this catches stuff like calling get_pages from
> > > put_pages (which isn't really a good idea, if we can call put_pages
> > > so could the shrinker). I've seen patches do exactly that.
> > >
> > > Of course I fully expect CI will show me for the fool I am with this
> > > one here :-)
> > >
> > > v2: There can only be one (lockdep only has a cache for the first
> > > subclass, not for deeper ones, and we don't want to make these locks
> > > even slower). Still separate enums for better documentation.
> > >
> > > Real fix: don forget about phys objs and pin_map(), and fix the
> > > shrinker to have the right annotations ... silly me.
> > >
> > > v3: Forgot usertptr too ...
> > >
> > > v4: Improve comment for pages_pin_count, drop the IMPORTANT
> comment
> > > and instead prime lockdep (Chris).
> > >
> > > Cc: Chris Wilson
> > > Cc: "Tang, CQ"
> > > Cc: Tvrtko Ursulin
> > > Cc: Joonas Lahtinen
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_object.c | 13 -
> > > drivers/gpu/drm/i915/gem/i915_gem_object.h | 16
> +---
> > > drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 6 +-
> > > drivers/gpu/drm/i915/gem/i915_gem_pages.c| 9 -
> > > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
> > > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 5 ++---
> > > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 ++--
> > > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++--
> > > 8 files changed, 45 insertions(+), 22 deletions(-)
> >
> > static inline int __must_check
> > i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) {
> > might_lock(>mm.lock);
> >
> > if (atomic_inc_not_zero(>mm.pages_pin_count))
> > return 0;
> >
> > return __i915_gem_object_get_pages(obj); }
> >
> > is now testing the wrong lock class.
>
> Unfortunately there's no might_lock_nested.
>
> But then, this is the best kind of wrong, because of the nesting we have:
>
> obj->mm.lock#I915_MM_GET_PAGES -> fs_reclaim -> obj->mm.lock
>
> So the might_lock we have actually checks for way more than just the "more
> correct" annotation. I think I'll just add the above as a comment and leave
> the code as-is. Thoughts?
I believe we should allow recursive call to i915_gem_object_pin_pages(), if
the object is already pinned, the next call just bump up the pin count and
return. Otherwise, you only allow paired call:
I915_gem_object_pin_pages(obj);
I915_gem_object_unpin_pages(obj);
Sometimes we need do this:
I915_gem_object_pin_pages(obj);
.
I915_gem_object_pin_pages(obj);
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Allow usage of all GPIO pins (rev3)
== Series Details == Series: drm/i915/gen11: Allow usage of all GPIO pins (rev3) URL : https://patchwork.freedesktop.org/series/65261/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6722 -> Patchwork_14066 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14066 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14066, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14066: ### IGT changes ### Possible regressions * igt@gem_sync@basic-store-each: - fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-cfl-8109u/igt@gem_s...@basic-store-each.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/fi-cfl-8109u/igt@gem_s...@basic-store-each.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-skl-6700k2: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html Warnings * igt@kms_chamelium@hdmi-hpd-fast: - fi-skl-6700k2: [FAIL][5] ([fdo#111407]) -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-skl-6700k2/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/fi-skl-6700k2/igt@kms_chamel...@hdmi-hpd-fast.html Known issues Here are the changes found in Patchwork_14066 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_gtt: - fi-glk-dsi: [PASS][7] -> [DMESG-WARN][8] ([fdo#110788]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-glk-dsi/igt@i915_selftest@live_gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/fi-glk-dsi/igt@i915_selftest@live_gtt.html * igt@kms_busy@basic-flip-a: - fi-skl-iommu: [PASS][9] -> [SKIP][10] ([fdo#109271] / [fdo#109278]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-skl-iommu/igt@kms_b...@basic-flip-a.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/fi-skl-iommu/igt@kms_b...@basic-flip-a.html - fi-skl-6260u: [PASS][11] -> [SKIP][12] ([fdo#109271] / [fdo#109278]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-skl-6260u/igt@kms_b...@basic-flip-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/fi-skl-6260u/igt@kms_b...@basic-flip-a.html - fi-bdw-gvtdvm: [PASS][13] -> [SKIP][14] ([fdo#109271] / [fdo#109278]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-bdw-gvtdvm/igt@kms_b...@basic-flip-a.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/fi-bdw-gvtdvm/igt@kms_b...@basic-flip-a.html * igt@kms_busy@basic-flip-b: - fi-bdw-5557u: [PASS][15] -> [SKIP][16] ([fdo#109271] / [fdo#109278]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-bdw-5557u/igt@kms_b...@basic-flip-b.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/fi-bdw-5557u/igt@kms_b...@basic-flip-b.html - fi-skl-gvtdvm: [PASS][17] -> [SKIP][18] ([fdo#109271] / [fdo#109278]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-skl-gvtdvm/igt@kms_b...@basic-flip-b.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/fi-skl-gvtdvm/igt@kms_b...@basic-flip-b.html - fi-cfl-guc: [PASS][19] -> [SKIP][20] ([fdo#109271] / [fdo#109278]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-cfl-guc/igt@kms_b...@basic-flip-b.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/fi-cfl-guc/igt@kms_b...@basic-flip-b.html - fi-cfl-8700k: [PASS][21] -> [SKIP][22] ([fdo#109271] / [fdo#109278]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-cfl-8700k/igt@kms_b...@basic-flip-b.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14066/fi-cfl-8700k/igt@kms_b...@basic-flip-b.html * igt@kms_chamelium@hdmi-crc-fast: - fi-skl-6700k2: [PASS][23] -> [FAIL][24] ([fdo#90]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-skl-6700k2/igt@kms_chamel...@hdmi-crc-fast.html [24]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use the associated uncore for the vm
== Series Details == Series: drm/i915: Use the associated uncore for the vm URL : https://patchwork.freedesktop.org/series/65291/ State : success == Summary == CI Bug Log - changes from CI_DRM_6716_full -> Patchwork_14047_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14047_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-apl4/igt@gem_ctx_isolat...@bcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-apl7/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-iclb7/igt@gem_exec_sched...@in-order-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-iclb4/igt@gem_exec_sched...@in-order-bsd.html * igt@gem_workarounds@suspend-resume-fd: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-skl7/igt@gem_workarou...@suspend-resume-fd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-skl8/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-snb6/igt@i915_pm_rc6_reside...@rc6-accuracy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-snb5/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding: - shard-hsw: [PASS][9] -> [INCOMPLETE][10] ([fdo#103540]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-hsw5/igt@kms_cursor_...@pipe-b-cursor-128x128-sliding.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-hsw5/igt@kms_cursor_...@pipe-b-cursor-128x128-sliding.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-random: - shard-apl: [PASS][11] -> [INCOMPLETE][12] ([fdo#103927]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-apl7/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-apl2/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html * igt@kms_cursor_crc@pipe-c-cursor-128x128-random: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103232]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-skl6/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html * igt@kms_flip@flip-vs-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([fdo#103313]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-kbl2/igt@kms_f...@flip-vs-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-kbl3/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-plflip-blt: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-plflip-blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-plflip-blt.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_no_drrs: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-iclb2/igt@kms_psr@psr2_no_drrs.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14047/shard-iclb7/igt@kms_psr@psr2_no_drrs.html * igt@perf@polling:
Re: [Intel-gfx] [PATCH v4] drm/i915/uc: Add explicit DISABLED state for firmware
Quoting Michal Wajdeczko (2019-08-16 21:56:58) > We really need to have separate NOT_SUPPORTED state (for > lack of hardware support) and DISABLED state (to indicate > user decision) as we will have to take special steps even > if GuC firmware is now disabled but hardware exists and > could have been previously used. > > v2: fix logic (Chris/CI) > v3: use proper check to avoid probe failure (CI) > v4: explain status transitions (Chris) > > Signed-off-by: Michal Wajdeczko > Cc: Daniele Ceraolo Spurio > Cc: Chris Wilson Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/kms: Catch mode_object lifetime errors
On Sat, 2019-06-29 at 17:39 +0200, Daniel Vetter wrote:
> On Fri, Jun 28, 2019 at 7:24 PM Sean Paul wrote:
> > On Fri, Jun 14, 2019 at 08:17:23AM +0200, Daniel Vetter wrote:
> > > Only dynamic mode objects, i.e. those which are refcounted and
> > > have a free
> > > callback, can be added while the overall drm_device is visible to
> > > userspace. All others must be added before drm_dev_register and
> > > removed after drm_dev_unregister.
> > >
> > > Small issue around drivers still using the load/unload callbacks,
> > > we
> > > need to make sure we set dev->registered so that load/unload code
> > > in
> > > these callbacks doesn't trigger false warnings. Only a small
> > > adjustement in drm_dev_register was needed.
> > >
> > > Motivated by some irc discussions about object ids of dynamic
> > > objects
> > > like blobs become invalid, and me going on a bit an audit spree.
> > >
> >
> > Seems like a very worthwhile change, any idea how many drivers are
> > going
> > to be sad after this change?
>
> None I think/hope, really just defense WARN_ON just in case. The main
> ones that would be sad are all the ones that have a ->load callback,
> but I'm taking care of them. Everyone else does things correctly and
> calls drm_dev_register last in their probe function (or around where
> they set up fbdev, which is also register the driver at least to the
> fbdev world, so really the same).
>
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 4 ++--
> > > drivers/gpu/drm/drm_mode_object.c | 4
> > > 2 files changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c
> > > b/drivers/gpu/drm/drm_drv.c
> > > index cb6f0245de7c..48c84e3e1931 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -997,14 +997,14 @@ int drm_dev_register(struct drm_device
> > > *dev, unsigned long flags)
> > > if (ret)
> > > goto err_minors;
> > >
> > > - dev->registered = true;
> > > -
> > > if (dev->driver->load) {
> > > ret = dev->driver->load(dev, flags);
> > > if (ret)
> > > goto err_minors;
> > > }
> > >
> > > + dev->registered = true;
> > > +
> > > if (drm_core_check_feature(dev, DRIVER_MODESET))
> > > drm_modeset_register_all(dev);
> > >
> > > diff --git a/drivers/gpu/drm/drm_mode_object.c
> > > b/drivers/gpu/drm/drm_mode_object.c
> > > index 1c6e51135962..c355ba8e6d5d 100644
> > > --- a/drivers/gpu/drm/drm_mode_object.c
> > > +++ b/drivers/gpu/drm/drm_mode_object.c
> > > @@ -42,6 +42,8 @@ int __drm_mode_object_add(struct drm_device
> > > *dev, struct drm_mode_object *obj,
> > > {
> > > int ret;
> > >
> > > + WARN_ON(dev->registered && !obj_free_cb);
Getting warnings on i915 with MST, we add fake MST connectors when a
sink with MST support is connected;
intel_dp_add_mst_connector()->drm_connector_attach_max_bpc_property()
Not sure how to fix that, add a global i915 device property like we do
for "audio" and "Broadcast RGB" don't look the right approach here.
Any tips?
We definitely need a platform with a MST sink on our CI.
> >
> > These should probably have a comment above them giving some
> > guidance to the
> > driver developer.
> >
> > With some comments, this is:
>
> What comment do you expect here? drm_dev_register explains what you
> should do already, and I expect driver developers to find that one
> pretty quickly. From there: "This should be done last in the device
> initialization sequence to make sure userspace can't access an
> inconsistent state."
> -Daniel
>
> > Reviewed-by: Sean Paul
> >
> >
> > > +
> > > mutex_lock(>mode_config.idr_mutex);
> > > ret = idr_alloc(>mode_config.object_idr, register_obj
> > > ? obj : NULL,
> > > 1, 0, GFP_KERNEL);
> > > @@ -102,6 +104,8 @@ void drm_mode_object_register(struct
> > > drm_device *dev,
> > > void drm_mode_object_unregister(struct drm_device *dev,
> > > struct drm_mode_object *object)
> > > {
> > > + WARN_ON(dev->registered && !object->free_cb);
> > > +
> > > mutex_lock(>mode_config.idr_mutex);
> > > if (object->id) {
> > > idr_remove(>mode_config.object_idr, object-
> > > >id);
> > > --
> > > 2.20.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
>
>
___
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/uc: Add explicit DISABLED state for firmware (rev4)
== Series Details ==
Series: drm/i915/uc: Add explicit DISABLED state for firmware (rev4)
URL : https://patchwork.freedesktop.org/series/65278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6722 -> Patchwork_14065
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14065/
Known issues
Here are the changes found in Patchwork_14065 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-small-bo-tiledy:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14065/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledy.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-icl-u3: [DMESG-WARN][3] ([fdo#107724]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14065/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_reset:
- {fi-icl-dsi}: [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-icl-dsi/igt@i915_selftest@live_reset.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14065/fi-icl-dsi/igt@i915_selftest@live_reset.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [DMESG-WARN][7] ([fdo#102614]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14065/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
- fi-icl-u2: [FAIL][9] ([fdo#103167]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6722/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14065/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
Participating hosts (53 -> 46)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6722 -> Patchwork_14065
CI-20190529: 20190529
CI_DRM_6722: fc0a986bb0fc167453d8054c1d5d5b44a9a1bb16 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14065: e52584745b18e618ee3ce1c431fee91e9d05f636 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e52584745b18 drm/i915/uc: Add explicit DISABLED state for firmware
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14065/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/selftests: Check the context size
On 8/16/19 3:13 PM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-08-16 22:50:43)
On 8/16/19 12:17 PM, Chris Wilson wrote:
+static int live_context_size(void *arg)
+{
+ /*
+ * Hide the old default state -- we lie about the context size
+ * and get confused when the default state is smaller than
+ * expected. For our do nothing request, inheriting the
+ * active state is sufficient, we are only checking that we
+ * don't use more than we planned.
+ */
+ saved.state = fetch_and_zero(>default_state);
+ saved.pinned = fetch_and_zero(>pinned_default_state);
+
+ engine->context_size += I915_GTT_PAGE_SIZE;
if CONFIG_DRM_I915_DEBUG_GEM is set we already bump the size inside the
context_alloc(), do we need to bump it again here?
No, it comes out in the wash as we apply the same redzone twice. At least,
adding and checking a second page after what we believe to be the end of
the context image does not help sensitivity (so makes a worse test imo).
The benefit of this selftest is that we check all submission modes, and
can set up any execution pattern we think might be required (within
reason). So, I think it still has a use even if we need to remind
ourselves of the overlap.
-Chris
Fair enough. With the above written down as a comment in the code:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/selftests: Check the context size
Quoting Daniele Ceraolo Spurio (2019-08-16 22:50:43)
>
>
> On 8/16/19 12:17 PM, Chris Wilson wrote:
> > +static int live_context_size(void *arg)
> > +{
> > + /*
> > + * Hide the old default state -- we lie about the context size
> > + * and get confused when the default state is smaller than
> > + * expected. For our do nothing request, inheriting the
> > + * active state is sufficient, we are only checking that we
> > + * don't use more than we planned.
> > + */
> > + saved.state = fetch_and_zero(>default_state);
> > + saved.pinned = fetch_and_zero(>pinned_default_state);
> > +
> > + engine->context_size += I915_GTT_PAGE_SIZE;
>
> if CONFIG_DRM_I915_DEBUG_GEM is set we already bump the size inside the
> context_alloc(), do we need to bump it again here?
No, it comes out in the wash as we apply the same redzone twice. At least,
adding and checking a second page after what we believe to be the end of
the context image does not help sensitivity (so makes a worse test imo).
The benefit of this selftest is that we check all submission modes, and
can set up any execution pattern we think might be required (within
reason). So, I think it still has a use even if we need to remind
ourselves of the overlap.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head
On Fri, Aug 16, 2019 at 9:23 PM Tang, CQ wrote:
>
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> > Sent: Friday, August 16, 2019 11:24 AM
> > To: Intel Graphics Development
> > Cc: Daniel Vetter ; Chris Wilson > wilson.co.uk>; Tang, CQ ; Ursulin, Tvrtko
> > ; Joonas Lahtinen
> > ; Vetter, Daniel
> > Subject: [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its
> > head
> >
> > The trouble with having a plain nesting flag for locks which do not
> > naturally
> > nest (unlike block devices and their partitions, which is the original
> > motivation
> > for nesting levels) is that lockdep will never spot a true deadlock if you
> > screw
> > up.
> >
> > This patch is an attempt at trying better, by highlighting a bit more the
> > actual
> > nature of the nesting that's going on. Essentially we have two kinds of
> > objects:
> >
> > - objects without pages allocated, which cannot be on any lru and are
> > hence inaccessible to the shrinker.
> >
> > - objects which have pages allocated, which are on an lru, and which
> > the shrinker can decide to throw out.
> >
> > For the former type of object, memory allcoations while holding
> > obj->mm.lock are permissible. For the latter they are not. And
> > get/put_pages transitions between the two types of objects.
> >
> > This is still not entirely fool-proof since the rules might chance.
> > But as long as we run such a code ever at runtime lockdep should be able to
> > observe the inconsistency and complain (like with any other lockdep class
> > that we've split up in multiple classes). But there are a few clear
> > benefits:
> >
> > - We can drop the nesting flag parameter from
> > __i915_gem_object_put_pages, because that function by definition is
> > never going allocate memory, and calling it on an object which
> > doesn't have its pages allocated would be a bug.
> >
> > - We strictly catch more bugs, since there's not only one place in the
> > entire tree which is annotated with the special class. All the
> > other places that had explicit lockdep nesting annotations we're now
> > going to leave up to lockdep again.
> >
> > - Specifically this catches stuff like calling get_pages from
> > put_pages (which isn't really a good idea, if we can call put_pages
> > so could the shrinker). I've seen patches do exactly that.
> >
> > Of course I fully expect CI will show me for the fool I am with this one
> > here :-)
> >
> > v2: There can only be one (lockdep only has a cache for the first subclass,
> > not
> > for deeper ones, and we don't want to make these locks even slower). Still
> > separate enums for better documentation.
> >
> > Real fix: don forget about phys objs and pin_map(), and fix the shrinker to
> > have the right annotations ... silly me.
> >
> > v3: Forgot usertptr too ...
> >
> > v4: Improve comment for pages_pin_count, drop the IMPORTANT comment
> > and instead prime lockdep (Chris).
> >
> > Cc: Chris Wilson
> > Cc: "Tang, CQ"
> > Cc: Tvrtko Ursulin
> > Cc: Joonas Lahtinen
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 13 -
> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 16 +---
> > drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 6 +-
> > drivers/gpu/drm/i915/gem/i915_gem_pages.c| 9 -
> > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
> > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 5 ++---
> > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 ++--
> > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++--
> > 8 files changed, 45 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index 3929c3a6b281..d01258b175f5 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -22,6 +22,8 @@
> > *
> > */
> >
> > +#include
> > +
> > #include "display/intel_frontbuffer.h"
> > #include "gt/intel_gt.h"
> > #include "i915_drv.h"
> > @@ -61,6 +63,15 @@ void i915_gem_object_init(struct
> > drm_i915_gem_object *obj, {
> > mutex_init(>mm.lock);
> >
> > + if (IS_ENABLED(CONFIG_LOCKDEP)) {
> > + mutex_lock_nested(>mm.lock,
> > I915_MM_GET_PAGES);
> > + fs_reclaim_acquire(GFP_KERNEL);
> > + might_lock(>mm.lock);
> > + fs_reclaim_release(GFP_KERNEL);
> > + mutex_unlock(>mm.lock);
> > + }
> > +
> > +
> > spin_lock_init(>vma.lock);
> > INIT_LIST_HEAD(>vma.list);
> >
> > @@ -191,7 +202,7 @@ static void __i915_gem_free_objects(struct
> > drm_i915_private *i915,
> > GEM_BUG_ON(!list_empty(>lut_list));
> >
> > atomic_set(>mm.pages_pin_count, 0);
> > - __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
> > + __i915_gem_object_put_pages(obj);
Re: [Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head
On Fri, Aug 16, 2019 at 8:46 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2019-08-16 19:23:36)
> > The trouble with having a plain nesting flag for locks which do not
> > naturally nest (unlike block devices and their partitions, which is
> > the original motivation for nesting levels) is that lockdep will
> > never spot a true deadlock if you screw up.
> >
> > This patch is an attempt at trying better, by highlighting a bit more
> > the actual nature of the nesting that's going on. Essentially we have
> > two kinds of objects:
> >
> > - objects without pages allocated, which cannot be on any lru and are
> > hence inaccessible to the shrinker.
> >
> > - objects which have pages allocated, which are on an lru, and which
> > the shrinker can decide to throw out.
> >
> > For the former type of object, memory allcoations while holding
> > obj->mm.lock are permissible. For the latter they are not. And
> > get/put_pages transitions between the two types of objects.
> >
> > This is still not entirely fool-proof since the rules might chance.
> > But as long as we run such a code ever at runtime lockdep should be
> > able to observe the inconsistency and complain (like with any other
> > lockdep class that we've split up in multiple classes). But there are
> > a few clear benefits:
> >
> > - We can drop the nesting flag parameter from
> > __i915_gem_object_put_pages, because that function by definition is
> > never going allocate memory, and calling it on an object which
> > doesn't have its pages allocated would be a bug.
> >
> > - We strictly catch more bugs, since there's not only one place in the
> > entire tree which is annotated with the special class. All the
> > other places that had explicit lockdep nesting annotations we're now
> > going to leave up to lockdep again.
> >
> > - Specifically this catches stuff like calling get_pages from
> > put_pages (which isn't really a good idea, if we can call put_pages
> > so could the shrinker). I've seen patches do exactly that.
> >
> > Of course I fully expect CI will show me for the fool I am with this
> > one here :-)
> >
> > v2: There can only be one (lockdep only has a cache for the first
> > subclass, not for deeper ones, and we don't want to make these locks
> > even slower). Still separate enums for better documentation.
> >
> > Real fix: don forget about phys objs and pin_map(), and fix the
> > shrinker to have the right annotations ... silly me.
> >
> > v3: Forgot usertptr too ...
> >
> > v4: Improve comment for pages_pin_count, drop the IMPORTANT comment
> > and instead prime lockdep (Chris).
> >
> > Cc: Chris Wilson
> > Cc: "Tang, CQ"
> > Cc: Tvrtko Ursulin
> > Cc: Joonas Lahtinen
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 13 -
> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 16 +---
> > drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 6 +-
> > drivers/gpu/drm/i915/gem/i915_gem_pages.c| 9 -
> > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
> > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 5 ++---
> > drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 ++--
> > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++--
> > 8 files changed, 45 insertions(+), 22 deletions(-)
>
> static inline int __must_check
> i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
> {
> might_lock(>mm.lock);
>
> if (atomic_inc_not_zero(>mm.pages_pin_count))
> return 0;
>
> return __i915_gem_object_get_pages(obj);
> }
>
> is now testing the wrong lock class.
Unfortunately there's no might_lock_nested.
But then, this is the best kind of wrong, because of the nesting we have:
obj->mm.lock#I915_MM_GET_PAGES -> fs_reclaim -> obj->mm.lock
So the might_lock we have actually checks for way more than just the
"more correct" annotation. I think I'll just add the above as a
comment and leave the code as-is. Thoughts?
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index 3929c3a6b281..d01258b175f5 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -22,6 +22,8 @@
> > *
> > */
> >
> > +#include
> > +
> > #include "display/intel_frontbuffer.h"
> > #include "gt/intel_gt.h"
> > #include "i915_drv.h"
> > @@ -61,6 +63,15 @@ void i915_gem_object_init(struct drm_i915_gem_object
> > *obj,
> > {
> > mutex_init(>mm.lock);
> >
> > + if (IS_ENABLED(CONFIG_LOCKDEP)) {
> > + mutex_lock_nested(>mm.lock, I915_MM_GET_PAGES);
> > + fs_reclaim_acquire(GFP_KERNEL);
> > + might_lock(>mm.lock);
> > + fs_reclaim_release(GFP_KERNEL);
> > + mutex_unlock(>mm.lock);
> > + }
>
> This is very powerful and sells a lot of churn.
Yeah that was the idea here. Plus I
Re: [Intel-gfx] [PATCH 08/39] drm/i915/tgl: Change PSR2 transcoder restriction
On Fri, 2019-08-16 at 14:28 -0700, Lucas De Marchi wrote:
> On Fri, Aug 16, 2019 at 1:05 AM Lucas De Marchi
> wrote:
> > From: José Roberto de Souza
> >
> > Tiger Lake has eDP-capable transcoders rather than a transcoder
> > dedicated to eDP. Transcoder A is the one where we have PSR2.
> > Actually transcoder B also supports PSR2 but only with software
> > tracking that is not implemented.
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 01070eb67571..1d36d7be015d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -511,12 +511,19 @@ static bool intel_psr2_config_valid(struct
> > intel_dp *intel_dp,
> > int crtc_hdisplay = crtc_state-
> > >base.adjusted_mode.crtc_hdisplay;
> > int crtc_vdisplay = crtc_state-
> > >base.adjusted_mode.crtc_vdisplay;
> > int psr_max_h = 0, psr_max_v = 0;
> > + enum transcoder supported;
> >
> > if (!dev_priv->psr.sink_psr2_support)
> > return false;
> >
> > - if (crtc_state->cpu_transcoder != TRANSCODER_EDP) {
> > - DRM_DEBUG_KMS("PSR2 is only supported in EDP
> > transcoder\n");
> > + /*
> > +* TODO: PSR2 is also supported in TRANSCODER_B on TGL+ but
> > it requires
> > +* software tracking
> > +*/
>
> where is this coming from? spec 49180 says: "Only transcoder A
> supports PSR2."
BSpec: 49274
Selective Update on second eDP
But or I misread or the platforms changed, TGL do not support PSR2 on
transcoder B even using manual tracking.
>
> Could this patch be squashed in "drm/i915: Add transcoder restriction
> to PSR2" so we just add the restriction
> for any platform at the same time?
Yes it now can be squashed, it was not before because I was trying to
upstream "drm/i915: Add transcoder restriction to PSR2" before TGL was
public.
I will fix both
Thanks
>
> Lucas De Marchi
>
> > + supported = INTEL_GEN(dev_priv) >= 12 ? TRANSCODER_A :
> > TRANSCODER_EDP;
> > + if (crtc_state->cpu_transcoder != supported) {
> > + DRM_DEBUG_KMS("PSR2 not supported in transcoder
> > %s\n",
> > + transcoder_name(supported));
> > return false;
> > }
> >
> > --
> > 2.21.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/selftests: Check the context size
On 8/16/19 12:17 PM, Chris Wilson wrote:
Add a redzone to our context image and check the HW does not write into
after a context save, to verify that we have the correct context size.
(This does vary with feature bits, so test with a live setup that should
match how we run userspace.)
v2: Check the redzone on every context unpin
v3: Use a kernel context to prevent loading garbage for ringbuffer
submission
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 33 ++
drivers/gpu/drm/i915/gt/selftest_context.c | 128 +
2 files changed, 161 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e9863f4d826b..ade212686bf6 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1578,9 +1578,38 @@ static void execlists_context_destroy(struct kref *kref)
intel_context_fini(ce);
intel_context_free(ce);
}
+static void
+set_redzone(void *vaddr, const struct intel_engine_cs *engine)
+{
+ if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ return;
+
+ vaddr += LRC_HEADER_PAGES * PAGE_SIZE;
+ vaddr += engine->context_size;
+
+ memset(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE);
+}
+
+static void
+check_redzone(const void *vaddr, const struct intel_engine_cs *engine)
+{
+ if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ return;
+
+ vaddr += LRC_HEADER_PAGES * PAGE_SIZE;
+ vaddr += engine->context_size;
+
+ if (memchr_inv(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE))
+ dev_err_once(engine->i915->drm.dev,
+"%s context redzone overwritten!\n",
+engine->name);
+}
static void execlists_context_unpin(struct intel_context *ce)
{
+ check_redzone((void *)ce->lrc_reg_state - LRC_STATE_PN * PAGE_SIZE,
+ ce->engine);
+
i915_gem_context_unpin_hw_id(ce->gem_context);
i915_gem_object_unpin_map(ce->state->obj);
intel_ring_reset(ce->ring, ce->ring->tail);
@@ -3119,6 +3148,8 @@ populate_lr_context(struct intel_context *ce,
return ret;
}
+ set_redzone(vaddr, engine);
+
if (engine->default_state) {
/*
* We only want to copy over the template context state;
@@ -3173,6 +3204,8 @@ static int __execlists_context_alloc(struct intel_context
*ce,
* for our own use and for sharing with the GuC.
*/
context_size += LRC_HEADER_PAGES * PAGE_SIZE;
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ context_size += I915_GTT_PAGE_SIZE; /* for redzone */
ctx_obj = i915_gem_object_create_shmem(engine->i915, context_size);
if (IS_ERR(ctx_obj))
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index 6fbc72bc290e..cefd2df086fb 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -5,6 +5,7 @@
*/
#include "i915_selftest.h"
+#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "gem/selftests/mock_context.h"
@@ -64,6 +65,132 @@ static int context_sync(struct intel_context *ce)
return err;
}
+static int __live_context_size(struct intel_engine_cs *engine,
+ struct i915_gem_context *fixme)
+{
+ struct intel_context *ce;
+ struct i915_request *rq;
+ void *vaddr;
+ int err;
+
+ ce = intel_context_create(fixme, engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ err = intel_context_pin(ce);
+ if (err)
+ goto err;
+
+ vaddr = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(engine->i915));
+ if (IS_ERR(vaddr)) {
+ err = PTR_ERR(vaddr);
+ intel_context_unpin(ce);
+ goto err;
+ }
+
+ if (HAS_EXECLISTS(engine->i915))
+ vaddr += LRC_HEADER_PAGES * PAGE_SIZE;
+
+ vaddr += engine->context_size - I915_GTT_PAGE_SIZE;
+ memset(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE);
+
+ rq = intel_context_create_request(ce);
+ intel_context_unpin(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_unpin;
+ }
+
+ err = request_sync(rq);
+ if (err)
+ goto err_unpin;
+
+ /* Force the context switch */
+ rq = i915_request_create(engine->kernel_context);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_unpin;
+ }
+ err = request_sync(rq);
+ if (err)
+ goto err_unpin;
+
+ if (memchr_inv(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE)) {
+ pr_err("%s context overwrote trailing red-zone!", engine->name);
+ err = -EINVAL;
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/connector: Allow max possible encoders to attach to a connector (rev2)
== Series Details ==
Series: drm/connector: Allow max possible encoders to attach to a connector
(rev2)
URL : https://patchwork.freedesktop.org/series/62743/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6721 -> Patchwork_14064
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14064/
Known issues
Here are the changes found in Patchwork_14064 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6721/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14064/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
* igt@kms_addfb_basic@addfb25-yf-tiled:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6721/fi-icl-u3/igt@kms_addfb_ba...@addfb25-yf-tiled.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14064/fi-icl-u3/igt@kms_addfb_ba...@addfb25-yf-tiled.html
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][5] ([fdo#08]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6721/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14064/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [SKIP][7] ([fdo#109271] / [fdo#109278]) -> [PASS][8]
+2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6721/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14064/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7567u: [FAIL][9] ([fdo#111407]) -> [FAIL][10] ([fdo#109800])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6721/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14064/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109800]: https://bugs.freedesktop.org/show_bug.cgi?id=109800
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (53 -> 43)
--
Missing(10): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-bxt-j4205 fi-icl-y fi-byt-clapper fi-bdw-samus fi-cml-u
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6721 -> Patchwork_14064
CI-20190529: 20190529
CI_DRM_6721: cbf9004bdfce80aff94fbd68ca0feb7fd76af0c4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14064: d3c689d47371fff179502454451af1be340f3668 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d3c689d47371 drm/connector: Allow max possible encoders to attach to a connector
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14064/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/connector: Allow max possible encoders to attach to a connector (rev2)
On Fri, 2019-08-16 at 21:29 +, Patchwork wrote: > == Series Details == > > Series: drm/connector: Allow max possible encoders to attach to a > connector (rev2) > URL : https://patchwork.freedesktop.org/series/62743/ > State : warning > > == Summary == > > $ dim sparse origin/drm-tip > Sparse version: v0.6.0 > Commit: drm/connector: Allow max possible encoders to attach to a > connector > + ^ > + } > +drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4802:1: > warning: control reaches end of non-void function [-Wreturn-type] > +drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In > function ‘amdgpu_dm_connector_to_encoder’: Missed a "return NULL;" that will not be reached. Will fix that in the next version after get some comments. > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/39] drm/i915/tgl: Change PSR2 transcoder restriction
On Fri, Aug 16, 2019 at 1:05 AM Lucas De Marchi
wrote:
>
> From: José Roberto de Souza
>
> Tiger Lake has eDP-capable transcoders rather than a transcoder
> dedicated to eDP. Transcoder A is the one where we have PSR2.
> Actually transcoder B also supports PSR2 but only with software
> tracking that is not implemented.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 01070eb67571..1d36d7be015d 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -511,12 +511,19 @@ static bool intel_psr2_config_valid(struct intel_dp
> *intel_dp,
> int crtc_hdisplay = crtc_state->base.adjusted_mode.crtc_hdisplay;
> int crtc_vdisplay = crtc_state->base.adjusted_mode.crtc_vdisplay;
> int psr_max_h = 0, psr_max_v = 0;
> + enum transcoder supported;
>
> if (!dev_priv->psr.sink_psr2_support)
> return false;
>
> - if (crtc_state->cpu_transcoder != TRANSCODER_EDP) {
> - DRM_DEBUG_KMS("PSR2 is only supported in EDP transcoder\n");
> + /*
> +* TODO: PSR2 is also supported in TRANSCODER_B on TGL+ but it
> requires
> +* software tracking
> +*/
where is this coming from? spec 49180 says: "Only transcoder A supports PSR2."
Could this patch be squashed in "drm/i915: Add transcoder restriction
to PSR2" so we just add the restriction
for any platform at the same time?
Lucas De Marchi
> + supported = INTEL_GEN(dev_priv) >= 12 ? TRANSCODER_A : TRANSCODER_EDP;
> + if (crtc_state->cpu_transcoder != supported) {
> + DRM_DEBUG_KMS("PSR2 not supported in transcoder %s\n",
> + transcoder_name(supported));
> return false;
> }
>
> --
> 2.21.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
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/connector: Allow max possible encoders to attach to a connector (rev2)
== Series Details == Series: drm/connector: Allow max possible encoders to attach to a connector (rev2) URL : https://patchwork.freedesktop.org/series/62743/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/connector: Allow max possible encoders to attach to a connector + ^ + } +drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4802:1: warning: control reaches end of non-void function [-Wreturn-type] +drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function ‘amdgpu_dm_connector_to_encoder’: ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/connector: Allow max possible encoders to attach to a connector (rev2)
== Series Details == Series: drm/connector: Allow max possible encoders to attach to a connector (rev2) URL : https://patchwork.freedesktop.org/series/62743/ State : warning == Summary == $ dim checkpatch origin/drm-tip d3c689d47371 drm/connector: Allow max possible encoders to attach to a connector -:582: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'connector' - possible side-effects? #582: FILE: include/drm/drm_connector.h:1612: +#define drm_connector_for_each_possible_encoder(connector, encoder) \ + drm_for_each_encoder_mask(encoder, (connector)->dev, \ + (connector)->possible_encoders) total: 0 errors, 0 warnings, 1 checks, 455 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Tiger Lake batch 3
== Series Details == Series: Tiger Lake batch 3 URL : https://patchwork.freedesktop.org/series/65290/ State : success == Summary == CI Bug Log - changes from CI_DRM_6716_full -> Patchwork_14046_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14046_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][1] -> [INCOMPLETE][2] ([fdo#103665]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-kbl3/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-kbl3/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-iclb7/igt@gem_exec_sched...@pi-ringfull-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-iclb2/igt@gem_exec_sched...@pi-ringfull-bsd.html * igt@i915_pm_rpm@fences: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] / [fdo#108840]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-iclb8/igt@i915_pm_...@fences.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-iclb2/igt@i915_pm_...@fences.html * igt@i915_selftest@live_hugepages: - shard-snb: [PASS][7] -> [INCOMPLETE][8] ([fdo#105411]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-snb7/igt@i915_selftest@live_hugepages.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-snb6/igt@i915_selftest@live_hugepages.html * igt@kms_cursor_crc@pipe-c-cursor-128x128-random: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103232]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([fdo#110741]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([fdo#108566]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-apl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-apl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#104873]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-glk8/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-glk8/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_flip@plain-flip-fb-recreate: - shard-kbl: [PASS][17] -> [FAIL][18] ([fdo#100368]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-kbl3/igt@kms_f...@plain-flip-fb-recreate.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-kbl1/igt@kms_f...@plain-flip-fb-recreate.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [fdo#110403]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14046/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_no_drrs: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) +1 similar issue
Re: [Intel-gfx] [PATCH 0/6] Some more display uncore prep work
Quoting Daniele Ceraolo Spurio (2019-08-16 02:23:37) > drm/i915: Move i915_power_well_id out of i915_reg.h > drm/i915: Move engine IDs out of i915_reg.h > drm/i915: Move gmbus definitions out of i915_reg.h > drm/i915: Wrappers for display register waits I pushed the simple and uncontroversial ones. Thanks, -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 drm/i915: Always wrap the ring offset before resetting
== Series Details == Series: drm/i915: Always wrap the ring offset before resetting URL : https://patchwork.freedesktop.org/series/65329/ State : success == Summary == CI Bug Log - changes from CI_DRM_6721 -> Patchwork_14063 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14063/ Known issues Here are the changes found in Patchwork_14063 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_create@basic-files: - fi-icl-u3: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / [fdo#109100]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6721/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14063/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html Warnings * igt@i915_pm_rpm@basic-pci-d3-state: - fi-kbl-guc: [SKIP][3] ([fdo#109271]) -> [FAIL][4] ([fdo#110829]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6721/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14063/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#110829]: https://bugs.freedesktop.org/show_bug.cgi?id=110829 Participating hosts (53 -> 45) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6721 -> Patchwork_14063 CI-20190529: 20190529 CI_DRM_6721: cbf9004bdfce80aff94fbd68ca0feb7fd76af0c4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14063: 26a77d3a6cde4bb3ed3f557e5f490c61dd1f86bf @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 26a77d3a6cde drm/i915: Always wrap the ring offset before resetting == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14063/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915/uc: Add explicit DISABLED state for firmware
We really need to have separate NOT_SUPPORTED state (for
lack of hardware support) and DISABLED state (to indicate
user decision) as we will have to take special steps even
if GuC firmware is now disabled but hardware exists and
could have been previously used.
v2: fix logic (Chris/CI)
v3: use proper check to avoid probe failure (CI)
v4: explain status transitions (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 7 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 7 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 37 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 17 -
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 +--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 43 +++
drivers/gpu/drm/i915/i915_drv.h | 4 +--
8 files changed, 91 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 4999db965685..2b2f046d3cc3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -154,7 +154,12 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc
*guc, u32 size);
static inline bool intel_guc_is_supported(struct intel_guc *guc)
{
- return intel_uc_fw_supported(>fw);
+ return intel_uc_fw_is_supported(>fw);
+}
+
+static inline bool intel_guc_is_enabled(struct intel_guc *guc)
+{
+ return intel_uc_fw_is_enabled(>fw);
}
static inline bool intel_guc_is_running(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index f8a4557c8d6d..644c059fe01d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -38,7 +38,12 @@ static inline int intel_huc_sanitize(struct intel_huc *huc)
static inline bool intel_huc_is_supported(struct intel_huc *huc)
{
- return intel_uc_fw_supported(>fw);
+ return intel_uc_fw_is_supported(>fw);
+}
+
+static inline bool intel_huc_is_enabled(struct intel_huc *huc)
+{
+ return intel_uc_fw_is_enabled(>fw);
}
static inline bool intel_huc_is_authenticated(struct intel_huc *huc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 96feca99322a..74602487ed67 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -35,7 +35,7 @@ void intel_huc_fw_init_early(struct intel_huc *huc)
struct drm_i915_private *i915 = gt->i915;
intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC,
- intel_uc_supports_guc(uc),
+ intel_uc_uses_guc(uc),
INTEL_INFO(i915)->platform, INTEL_REVID(i915));
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 0dc2b0cf4604..449c432dd768 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -45,17 +45,17 @@ static void __confirm_options(struct intel_uc *uc)
DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
"enable_guc=%d (guc:%s submission:%s huc:%s)\n",
i915_modparams.enable_guc,
-yesno(intel_uc_supports_guc(uc)),
-yesno(intel_uc_supports_guc_submission(uc)),
-yesno(intel_uc_supports_huc(uc)));
+yesno(intel_uc_uses_guc(uc)),
+yesno(intel_uc_uses_guc_submission(uc)),
+yesno(intel_uc_uses_huc(uc)));
if (i915_modparams.enable_guc == -1)
return;
if (i915_modparams.enable_guc == 0) {
- GEM_BUG_ON(intel_uc_supports_guc(uc));
- GEM_BUG_ON(intel_uc_supports_guc_submission(uc));
- GEM_BUG_ON(intel_uc_supports_huc(uc));
+ GEM_BUG_ON(intel_uc_uses_guc(uc));
+ GEM_BUG_ON(intel_uc_uses_guc_submission(uc));
+ GEM_BUG_ON(intel_uc_uses_huc(uc));
return;
}
@@ -266,23 +266,23 @@ void intel_uc_fetch_firmwares(struct intel_uc *uc)
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
int err;
- if (!intel_uc_supports_guc(uc))
+ if (!intel_uc_uses_guc(uc))
return;
err = intel_uc_fw_fetch(>guc.fw, i915);
if (err)
return;
- if (intel_uc_supports_huc(uc))
+ if (intel_uc_uses_huc(uc))
intel_uc_fw_fetch(>huc.fw, i915);
}
void intel_uc_cleanup_firmwares(struct intel_uc *uc)
{
- if (!intel_uc_supports_guc(uc))
+ if (!intel_uc_uses_guc(uc))
return;
- if (intel_uc_supports_huc(uc))
+ if (intel_uc_uses_huc(uc))
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Always wrap the ring offset before resetting
== Series Details == Series: drm/i915: Always wrap the ring offset before resetting URL : https://patchwork.freedesktop.org/series/65329/ State : warning == Summary == $ dim checkpatch origin/drm-tip 26a77d3a6cde drm/i915: Always wrap the ring offset before resetting -:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: <3> [314.872147] intel_ring_reset:1237 GEM_BUG_ON(!intel_ring_offset_valid(ring, tail)) total: 0 errors, 1 warnings, 0 checks, 9 lines checked ___ 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: Check the context size (rev3)
== Series Details ==
Series: drm/i915/selftests: Check the context size (rev3)
URL : https://patchwork.freedesktop.org/series/65323/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6721 -> Patchwork_14062
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14062/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14062:
### 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_timelines}:
- fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6721/fi-hsw-peppy/igt@i915_selftest@live_gt_timelines.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14062/fi-hsw-peppy/igt@i915_selftest@live_gt_timelines.html
Known issues
Here are the changes found in Patchwork_14062 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@bad-open:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6721/fi-icl-u3/igt@gem_flink_ba...@bad-open.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14062/fi-icl-u3/igt@gem_flink_ba...@bad-open.html
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][5] ([fdo#08]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6721/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14062/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
Participating hosts (53 -> 46)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6721 -> Patchwork_14062
CI-20190529: 20190529
CI_DRM_6721: cbf9004bdfce80aff94fbd68ca0feb7fd76af0c4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14062: 592028b70fabc0065c9c23dc39dd9d4ef57334d8 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
592028b70fab drm/i915/selftests: Check the context size
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14062/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Check the context size (rev3)
== Series Details == Series: drm/i915/selftests: Check the context size (rev3) URL : https://patchwork.freedesktop.org/series/65323/ State : warning == Summary == $ dim checkpatch origin/drm-tip 592028b70fab drm/i915/selftests: Check the context size -:26: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #26: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1581: } +static void total: 0 errors, 0 warnings, 1 checks, 200 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/connector: Allow max possible encoders to attach to a connector
From: Dhinakaran Pandiyan
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).
To more effiently do that lets switch from an array of encoder ids to
bitmask.
Also removing the best_encoder hook from the drivers that only have
one encoder per connector(this ones have one encoder in the whole
driver), pick_single_encoder_for_connector() will do the same job
with no functional change.
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Alex Deucher
Cc: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 23 +-
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 5 ++-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++-
drivers/gpu/drm/ast/ast_mode.c| 12 ---
drivers/gpu/drm/drm_atomic_helper.c | 9 --
drivers/gpu/drm/drm_client_modeset.c | 3 +-
drivers/gpu/drm/drm_connector.c | 31 +--
drivers/gpu/drm/drm_probe_helper.c| 3 +-
drivers/gpu/drm/mgag200/mgag200_mode.c| 11 ---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 7 ++---
drivers/gpu/drm/radeon/radeon_connectors.c| 27 ++--
drivers/gpu/drm/udl/udl_connector.c | 8 -
include/drm/drm_connector.h | 18 +--
15 files changed, 53 insertions(+), 114 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index ece55c8fa673..d8729285f731 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -217,11 +217,10 @@ amdgpu_connector_update_scratch_regs(struct drm_connector
*connector,
struct drm_encoder *encoder;
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
bool connected;
- int i;
best_encoder = connector_funcs->best_encoder(connector);
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if ((encoder == best_encoder) && (status ==
connector_status_connected))
connected = true;
else
@@ -236,9 +235,8 @@ amdgpu_connector_find_encoder(struct drm_connector
*connector,
int encoder_type)
{
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (encoder->encoder_type == encoder_type)
return encoder;
}
@@ -347,10 +345,9 @@ static struct drm_encoder *
amdgpu_connector_best_single_encoder(struct drm_connector *connector)
{
struct drm_encoder *encoder;
- int i;
/* pick the first one */
- drm_connector_for_each_possible_encoder(connector, encoder, i)
+ drm_connector_for_each_possible_encoder(connector, encoder)
return encoder;
return NULL;
@@ -1065,9 +1062,8 @@ amdgpu_connector_dvi_detect(struct drm_connector
*connector, bool force)
/* find analog encoder */
if (amdgpu_connector->dac_load_detect) {
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (encoder->encoder_type != DRM_MODE_ENCODER_DAC &&
encoder->encoder_type != DRM_MODE_ENCODER_TVDAC)
continue;
@@ -1117,9 +1113,8 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
{
struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (amdgpu_connector->use_digital == true) {
if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
return encoder;
@@ -1134,7 +1129,7 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
/* then check use digitial */
/* pick the first one */
- drm_connector_for_each_possible_encoder(connector, encoder, i)
+ drm_connector_for_each_possible_encoder(connector, encoder)
return encoder;
return NULL;
@@ -1271,9
Re: [Intel-gfx] [PATCH] drm/i915/gen11: Allow usage of all GPIO pins
On Thu, 2019-08-15 at 15:39 -0700, Matt Roper wrote:
> Our pin mapping tables for ICP and MCC currently only list the
> standard
> GPIO pins used for various output ports. Even through ICP's standard
> pin usage only utilizes pins 1, 2, and 9-12, and MCC's standard pin
> usage only uses pins 1, 2, and 9, these platforms do still have GPIO
> registers to address pins in the range 1-3 and 9-14. OEM's may remap
> GPIO usage in non-standard ways (and provide the actual mapping via
> VBT
> settings), so we shouldn't exclude pins on these platforms just
> because
> they aren't part of the standard mappings.
>
> TGP's standard pin tables contains all the possible pins, so let's
> rename them to "icp" and use them for all PCH >= PCH_ICP. This will
> prevent intel_gmbus_is_valid_pin from rejecting non-standard pin
> usage
> that an OEM specifies via the VBT.
>
> Note that this will cause pin 9 to be labeled as "tc1" instead of
> "dpc"
> in debug messages on platforms with the MCC PCH, but that may
> actually
> help avoid confusion since the text strings will now be the same on
> all
> gen11+ platforms instead of being different on just EHL.
>
> v2: Drop now-unused MCC_DDC_BUS_DDI_* names.
>
Reviewed-by: José Roberto de Souza
> Bspec: 8417
> Cc: José Roberto de Souza
> Cc: Lucas De Marchi
> Cc: Vivek Kasireddy
> Cc: Jani Nikula
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 23 +---
> drivers/gpu/drm/i915/display/intel_gmbus.c| 27 ++---
> --
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 3 ---
> 3 files changed, 3 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index b416b394b641..ed608f2df130 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1341,21 +1341,6 @@ static const u8 cnp_ddc_pin_map[] = {
> };
>
> static const u8 icp_ddc_pin_map[] = {
> - [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
> - [ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
> - [ICL_DDC_BUS_PORT_1] = GMBUS_PIN_9_TC1_ICP,
> - [ICL_DDC_BUS_PORT_2] = GMBUS_PIN_10_TC2_ICP,
> - [ICL_DDC_BUS_PORT_3] = GMBUS_PIN_11_TC3_ICP,
> - [ICL_DDC_BUS_PORT_4] = GMBUS_PIN_12_TC4_ICP,
> -};
> -
> -static const u8 mcc_ddc_pin_map[] = {
> - [MCC_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
> - [MCC_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
> - [MCC_DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
> -};
> -
> -static const u8 tgp_ddc_pin_map[] = {
> [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
> [ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
> [TGL_DDC_BUS_DDI_C] = GMBUS_PIN_3_BXT,
> @@ -1372,13 +1357,7 @@ static u8 map_ddc_pin(struct drm_i915_private
> *dev_priv, u8 vbt_pin)
> const u8 *ddc_pin_map;
> int n_entries;
>
> - if (HAS_PCH_TGP(dev_priv)) {
> - ddc_pin_map = tgp_ddc_pin_map;
> - n_entries = ARRAY_SIZE(tgp_ddc_pin_map);
> - } else if (HAS_PCH_MCC(dev_priv)) {
> - ddc_pin_map = mcc_ddc_pin_map;
> - n_entries = ARRAY_SIZE(mcc_ddc_pin_map);
> - } else if (HAS_PCH_ICP(dev_priv)) {
> + if (INTEL_PCH_ID(dev_priv) >= PCH_ICP) {
> ddc_pin_map = icp_ddc_pin_map;
> n_entries = ARRAY_SIZE(icp_ddc_pin_map);
> } else if (HAS_PCH_CNP(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
> b/drivers/gpu/drm/i915/display/intel_gmbus.c
> index 1e27b18aa3fc..3ac8a5c0b4b5 100644
> --- a/drivers/gpu/drm/i915/display/intel_gmbus.c
> +++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
> @@ -80,21 +80,6 @@ static const struct gmbus_pin gmbus_pins_cnp[] = {
> };
>
> static const struct gmbus_pin gmbus_pins_icp[] = {
> - [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
> - [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
> - [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
> - [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOK },
> - [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOL },
> - [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOM },
> -};
> -
> -static const struct gmbus_pin gmbus_pins_mcc[] = {
> - [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
> - [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
> - [GMBUS_PIN_9_TC1_ICP] = { "dpc", GPIOJ },
> -};
> -
> -static const struct gmbus_pin gmbus_pins_tgp[] = {
> [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
> [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
> [GMBUS_PIN_3_BXT] = { "dpc", GPIOD },
> @@ -110,11 +95,7 @@ static const struct gmbus_pin gmbus_pins_tgp[] =
> {
> static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private
> *dev_priv,
>unsigned int pin)
> {
> - if (HAS_PCH_TGP(dev_priv))
> - return _pins_tgp[pin];
> - else if (HAS_PCH_MCC(dev_priv))
> - return _pins_mcc[pin];
> - else if (HAS_PCH_ICP(dev_priv))
> + if (INTEL_PCH_ID(dev_priv) >= PCH_ICP)
> return _pins_icp[pin];
> else if
[Intel-gfx] [PATCH] drm/i915: Always wrap the ring offset before resetting
We were passing in an unwrapped offset into intel_ring_reset() on
unpinning. Sooner or later that had to land on ring->size.
<3> [314.872147] intel_ring_reset:1237
GEM_BUG_ON(!intel_ring_offset_valid(ring, tail))
<4> [314.872272] [ cut here ]
<2> [314.872276] kernel BUG at drivers/gpu/drm/i915/gt/intel_ringbuffer.c:1237!
<4> [314.872320] invalid opcode: [#1] PREEMPT SMP PTI
<4> [314.872331] CPU: 1 PID: 3466 Comm: i915_selftest Tainted: G U
5.3.0-rc4-CI-Patchwork_14061+ #1
<4> [314.872346] Hardware name: Hewlett-Packard HP Compaq 8000 Elite CMT
PC/3647h, BIOS 786G7 v01.02 10/22/2009
<4> [314.872477] RIP: 0010:intel_ring_reset+0x51/0x70 [i915]
<4> [314.872487] Code: 9e db 51 e0 48 8b 35 b6 c7 22 00 49 c7 c0 f8 d9 d6 a0 b9
d5 04 00 00 48 c7 c2 70 5b d4 a0 48 c7 c7 6c fc c0 a0 e8 cf be 58 e0 <0f> 0b 89
77 20 89 77 1c 89 77 24 e9 4f ed ff ff 0f 1f 44 00 00 66
<4> [314.872512] RSP: 0018:c934fa98 EFLAGS: 00010282
<4> [314.872523] RAX: 0010 RBX: 8881019412c8 RCX:
<4> [314.872534] RDX: 0001 RSI: 0008 RDI:
0f20
<4> [314.872545] RBP: 888104e0f740 R08: R09:
0f20
<4> [314.872557] R10: R11: 888117094518 R12:
a0d3d2c0
<4> [314.872569] R13: a0e2a250 R14: a0e2a1e0 R15:
c934fe88
<4> [314.872581] FS: 7fe6d49f6e40() GS:888117a8()
knlGS:
<4> [314.872595] CS: 0010 DS: ES: CR0: 80050033
<4> [314.872605] CR2: 55e3283e9cc8 CR3: 000108842000 CR4:
000406e0
<4> [314.872616] Call Trace:
<4> [314.872701] intel_ring_unpin+0x1a/0x220 [i915]
<4> [314.872787] ring_destroy+0x48/0xc0 [i915]
<4> [314.872870] intel_engines_cleanup+0x24/0x40 [i915]
<4> [314.872964] i915_gem_driver_release+0x1b/0xf0 [i915]
<4> [314.872984] i915_driver_release+0x1c/0x80 [i915]
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
index 1d9c125b76d0..601c16239fdf 100644
--- a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
@@ -1234,8 +1234,7 @@ int intel_ring_pin(struct intel_ring *ring)
void intel_ring_reset(struct intel_ring *ring, u32 tail)
{
- GEM_BUG_ON(!intel_ring_offset_valid(ring, tail));
-
+ tail = intel_ring_wrap(ring, tail);
ring->tail = tail;
ring->head = tail;
ring->emit = tail;
--
2.23.0.rc1
___
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: Switch obj->mm.lock lockdep annotations on its head
== Series Details == Series: drm/i915: Switch obj->mm.lock lockdep annotations on its head URL : https://patchwork.freedesktop.org/series/65326/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6720 -> Patchwork_14061 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14061 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14061, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14061/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14061: ### IGT changes ### Possible regressions * igt@runner@aborted: - fi-elk-e7500: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14061/fi-elk-e7500/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_14061 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_requests: - fi-elk-e7500: [PASS][2] -> [INCOMPLETE][3] ([fdo#103989]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-elk-e7500/igt@i915_selftest@live_requests.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14061/fi-elk-e7500/igt@i915_selftest@live_requests.html * igt@kms_addfb_basic@unused-handle: - fi-icl-u3: [PASS][4] -> [DMESG-WARN][5] ([fdo#107724]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u3/igt@kms_addfb_ba...@unused-handle.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14061/fi-icl-u3/igt@kms_addfb_ba...@unused-handle.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [PASS][6] -> [DMESG-WARN][7] ([fdo#102614]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14061/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@i915_module_load@reload: - fi-icl-u3: [DMESG-WARN][8] ([fdo#107724]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u3/igt@i915_module_l...@reload.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14061/fi-icl-u3/igt@i915_module_l...@reload.html * igt@i915_selftest@live_execlists: - fi-skl-gvtdvm: [DMESG-FAIL][10] ([fdo#08]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14061/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html * igt@i915_selftest@live_hangcheck: - fi-icl-u2: [INCOMPLETE][12] ([fdo#107713] / [fdo#108569]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u2/igt@i915_selftest@live_hangcheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14061/fi-icl-u2/igt@i915_selftest@live_hangcheck.html Warnings * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][14] ([fdo#109483]) -> [FAIL][15] ([fdo#111407]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14061/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103989]: https://bugs.freedesktop.org/show_bug.cgi?id=103989 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483 [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 Participating hosts (54 -> 45) -- Missing(9): fi-kbl-soraka fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6720 -> Patchwork_14061 CI-20190529: 20190529 CI_DRM_6720: 7d0da9a1f86471d256afbc80f2cfa82e3aafa8ac @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14061: d55e4cd434ccb30dde1ad9064f20ee13ab6b69ae @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d55e4cd434cc drm/i915: Switch obj->mm.lock lockdep annotations on its head == Logs == For more details see:
Re: [Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Friday, August 16, 2019 11:24 AM
> To: Intel Graphics Development
> Cc: Daniel Vetter ; Chris Wilson wilson.co.uk>; Tang, CQ ; Ursulin, Tvrtko
> ; Joonas Lahtinen
> ; Vetter, Daniel
> Subject: [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its
> head
>
> The trouble with having a plain nesting flag for locks which do not naturally
> nest (unlike block devices and their partitions, which is the original
> motivation
> for nesting levels) is that lockdep will never spot a true deadlock if you
> screw
> up.
>
> This patch is an attempt at trying better, by highlighting a bit more the
> actual
> nature of the nesting that's going on. Essentially we have two kinds of
> objects:
>
> - objects without pages allocated, which cannot be on any lru and are
> hence inaccessible to the shrinker.
>
> - objects which have pages allocated, which are on an lru, and which
> the shrinker can decide to throw out.
>
> For the former type of object, memory allcoations while holding
> obj->mm.lock are permissible. For the latter they are not. And
> get/put_pages transitions between the two types of objects.
>
> This is still not entirely fool-proof since the rules might chance.
> But as long as we run such a code ever at runtime lockdep should be able to
> observe the inconsistency and complain (like with any other lockdep class
> that we've split up in multiple classes). But there are a few clear benefits:
>
> - We can drop the nesting flag parameter from
> __i915_gem_object_put_pages, because that function by definition is
> never going allocate memory, and calling it on an object which
> doesn't have its pages allocated would be a bug.
>
> - We strictly catch more bugs, since there's not only one place in the
> entire tree which is annotated with the special class. All the
> other places that had explicit lockdep nesting annotations we're now
> going to leave up to lockdep again.
>
> - Specifically this catches stuff like calling get_pages from
> put_pages (which isn't really a good idea, if we can call put_pages
> so could the shrinker). I've seen patches do exactly that.
>
> Of course I fully expect CI will show me for the fool I am with this one here
> :-)
>
> v2: There can only be one (lockdep only has a cache for the first subclass,
> not
> for deeper ones, and we don't want to make these locks even slower). Still
> separate enums for better documentation.
>
> Real fix: don forget about phys objs and pin_map(), and fix the shrinker to
> have the right annotations ... silly me.
>
> v3: Forgot usertptr too ...
>
> v4: Improve comment for pages_pin_count, drop the IMPORTANT comment
> and instead prime lockdep (Chris).
>
> Cc: Chris Wilson
> Cc: "Tang, CQ"
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 13 -
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 16 +---
> drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 6 +-
> drivers/gpu/drm/i915/gem/i915_gem_pages.c| 9 -
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 5 ++---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 ++--
> drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++--
> 8 files changed, 45 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 3929c3a6b281..d01258b175f5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -22,6 +22,8 @@
> *
> */
>
> +#include
> +
> #include "display/intel_frontbuffer.h"
> #include "gt/intel_gt.h"
> #include "i915_drv.h"
> @@ -61,6 +63,15 @@ void i915_gem_object_init(struct
> drm_i915_gem_object *obj, {
> mutex_init(>mm.lock);
>
> + if (IS_ENABLED(CONFIG_LOCKDEP)) {
> + mutex_lock_nested(>mm.lock,
> I915_MM_GET_PAGES);
> + fs_reclaim_acquire(GFP_KERNEL);
> + might_lock(>mm.lock);
> + fs_reclaim_release(GFP_KERNEL);
> + mutex_unlock(>mm.lock);
> + }
> +
> +
> spin_lock_init(>vma.lock);
> INIT_LIST_HEAD(>vma.list);
>
> @@ -191,7 +202,7 @@ static void __i915_gem_free_objects(struct
> drm_i915_private *i915,
> GEM_BUG_ON(!list_empty(>lut_list));
>
> atomic_set(>mm.pages_pin_count, 0);
> - __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
> + __i915_gem_object_put_pages(obj);
> GEM_BUG_ON(i915_gem_object_has_pages(obj));
> bitmap_free(obj->bit_17);
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 3714cf234d64..5ce511ca7fa8 100644
> ---
[Intel-gfx] [PATCH v3] drm/i915/selftests: Check the context size
Add a redzone to our context image and check the HW does not write into
after a context save, to verify that we have the correct context size.
(This does vary with feature bits, so test with a live setup that should
match how we run userspace.)
v2: Check the redzone on every context unpin
v3: Use a kernel context to prevent loading garbage for ringbuffer
submission
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 33 ++
drivers/gpu/drm/i915/gt/selftest_context.c | 128 +
2 files changed, 161 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e9863f4d826b..ade212686bf6 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1578,9 +1578,38 @@ static void execlists_context_destroy(struct kref *kref)
intel_context_fini(ce);
intel_context_free(ce);
}
+static void
+set_redzone(void *vaddr, const struct intel_engine_cs *engine)
+{
+ if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ return;
+
+ vaddr += LRC_HEADER_PAGES * PAGE_SIZE;
+ vaddr += engine->context_size;
+
+ memset(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE);
+}
+
+static void
+check_redzone(const void *vaddr, const struct intel_engine_cs *engine)
+{
+ if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ return;
+
+ vaddr += LRC_HEADER_PAGES * PAGE_SIZE;
+ vaddr += engine->context_size;
+
+ if (memchr_inv(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE))
+ dev_err_once(engine->i915->drm.dev,
+"%s context redzone overwritten!\n",
+engine->name);
+}
static void execlists_context_unpin(struct intel_context *ce)
{
+ check_redzone((void *)ce->lrc_reg_state - LRC_STATE_PN * PAGE_SIZE,
+ ce->engine);
+
i915_gem_context_unpin_hw_id(ce->gem_context);
i915_gem_object_unpin_map(ce->state->obj);
intel_ring_reset(ce->ring, ce->ring->tail);
@@ -3119,6 +3148,8 @@ populate_lr_context(struct intel_context *ce,
return ret;
}
+ set_redzone(vaddr, engine);
+
if (engine->default_state) {
/*
* We only want to copy over the template context state;
@@ -3173,6 +3204,8 @@ static int __execlists_context_alloc(struct intel_context
*ce,
* for our own use and for sharing with the GuC.
*/
context_size += LRC_HEADER_PAGES * PAGE_SIZE;
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ context_size += I915_GTT_PAGE_SIZE; /* for redzone */
ctx_obj = i915_gem_object_create_shmem(engine->i915, context_size);
if (IS_ERR(ctx_obj))
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index 6fbc72bc290e..cefd2df086fb 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -5,6 +5,7 @@
*/
#include "i915_selftest.h"
+#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "gem/selftests/mock_context.h"
@@ -64,6 +65,132 @@ static int context_sync(struct intel_context *ce)
return err;
}
+static int __live_context_size(struct intel_engine_cs *engine,
+ struct i915_gem_context *fixme)
+{
+ struct intel_context *ce;
+ struct i915_request *rq;
+ void *vaddr;
+ int err;
+
+ ce = intel_context_create(fixme, engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ err = intel_context_pin(ce);
+ if (err)
+ goto err;
+
+ vaddr = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(engine->i915));
+ if (IS_ERR(vaddr)) {
+ err = PTR_ERR(vaddr);
+ intel_context_unpin(ce);
+ goto err;
+ }
+
+ if (HAS_EXECLISTS(engine->i915))
+ vaddr += LRC_HEADER_PAGES * PAGE_SIZE;
+
+ vaddr += engine->context_size - I915_GTT_PAGE_SIZE;
+ memset(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE);
+
+ rq = intel_context_create_request(ce);
+ intel_context_unpin(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_unpin;
+ }
+
+ err = request_sync(rq);
+ if (err)
+ goto err_unpin;
+
+ /* Force the context switch */
+ rq = i915_request_create(engine->kernel_context);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_unpin;
+ }
+ err = request_sync(rq);
+ if (err)
+ goto err_unpin;
+
+ if (memchr_inv(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE)) {
+ pr_err("%s context overwrote trailing red-zone!", engine->name);
+ err = -EINVAL;
+ }
+
+err_unpin:
+
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Check the context size
== Series Details == Series: drm/i915/selftests: Check the context size URL : https://patchwork.freedesktop.org/series/65323/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6720 -> Patchwork_14060 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14060 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14060, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14060: ### IGT changes ### Possible regressions * igt@i915_selftest@live_gt_contexts: - fi-hsw-4770r: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-hsw-4770r/igt@i915_selftest@live_gt_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-hsw-4770r/igt@i915_selftest@live_gt_contexts.html - fi-elk-e7500: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-elk-e7500/igt@i915_selftest@live_gt_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-elk-e7500/igt@i915_selftest@live_gt_contexts.html - fi-snb-2600:[PASS][5] -> [DMESG-FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-snb-2600/igt@i915_selftest@live_gt_contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-snb-2600/igt@i915_selftest@live_gt_contexts.html - fi-hsw-peppy: [PASS][7] -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-hsw-peppy/igt@i915_selftest@live_gt_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-hsw-peppy/igt@i915_selftest@live_gt_contexts.html - fi-snb-2520m: [PASS][9] -> [DMESG-FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-snb-2520m/igt@i915_selftest@live_gt_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-snb-2520m/igt@i915_selftest@live_gt_contexts.html - fi-ilk-650: [PASS][11] -> [DMESG-FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-ilk-650/igt@i915_selftest@live_gt_contexts.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-ilk-650/igt@i915_selftest@live_gt_contexts.html - fi-hsw-4770:[PASS][13] -> [DMESG-FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-hsw-4770/igt@i915_selftest@live_gt_contexts.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-hsw-4770/igt@i915_selftest@live_gt_contexts.html Known issues Here are the changes found in Patchwork_14060 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_switch@legacy-render: - fi-bxt-dsi: [PASS][15] -> [INCOMPLETE][16] ([fdo#103927]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html - fi-bxt-j4205: [PASS][17] -> [INCOMPLETE][18] ([fdo#103927]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-bxt-j4205/igt@gem_ctx_swi...@legacy-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-bxt-j4205/igt@gem_ctx_swi...@legacy-render.html * igt@prime_vgem@basic-fence-flip: - fi-icl-u3: [PASS][19] -> [DMESG-WARN][20] ([fdo#107724]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u3/igt@prime_v...@basic-fence-flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-icl-u3/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@i915_module_load@reload: - fi-icl-u3: [DMESG-WARN][21] ([fdo#107724]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u3/igt@i915_module_l...@reload.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-icl-u3/igt@i915_module_l...@reload.html * igt@i915_selftest@live_execlists: - fi-skl-gvtdvm: [DMESG-FAIL][23] ([fdo#08]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14060/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html * igt@i915_selftest@live_hangcheck: - fi-icl-u2: [INCOMPLETE][25] ([fdo#107713] / [fdo#108569]) -> [PASS][26] [25]:
[Intel-gfx] [PATCH v2] drm/i915/selftests: Check the context size
Add a redzone to our context image and check the HW does not write into
after a context save, to verify that we have the correct context size.
(This does vary with feature bits, so test with a live setup that should
match how we run userspace.)
v2: Check the redzone on every context unpin
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 33 +
drivers/gpu/drm/i915/gt/selftest_context.c | 133 +
2 files changed, 166 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e9863f4d826b..ade212686bf6 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1578,9 +1578,38 @@ static void execlists_context_destroy(struct kref *kref)
intel_context_fini(ce);
intel_context_free(ce);
}
+static void
+set_redzone(void *vaddr, const struct intel_engine_cs *engine)
+{
+ if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ return;
+
+ vaddr += LRC_HEADER_PAGES * PAGE_SIZE;
+ vaddr += engine->context_size;
+
+ memset(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE);
+}
+
+static void
+check_redzone(const void *vaddr, const struct intel_engine_cs *engine)
+{
+ if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ return;
+
+ vaddr += LRC_HEADER_PAGES * PAGE_SIZE;
+ vaddr += engine->context_size;
+
+ if (memchr_inv(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE))
+ dev_err_once(engine->i915->drm.dev,
+"%s context redzone overwritten!\n",
+engine->name);
+}
static void execlists_context_unpin(struct intel_context *ce)
{
+ check_redzone((void *)ce->lrc_reg_state - LRC_STATE_PN * PAGE_SIZE,
+ ce->engine);
+
i915_gem_context_unpin_hw_id(ce->gem_context);
i915_gem_object_unpin_map(ce->state->obj);
intel_ring_reset(ce->ring, ce->ring->tail);
@@ -3119,6 +3148,8 @@ populate_lr_context(struct intel_context *ce,
return ret;
}
+ set_redzone(vaddr, engine);
+
if (engine->default_state) {
/*
* We only want to copy over the template context state;
@@ -3173,6 +3204,8 @@ static int __execlists_context_alloc(struct intel_context
*ce,
* for our own use and for sharing with the GuC.
*/
context_size += LRC_HEADER_PAGES * PAGE_SIZE;
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ context_size += I915_GTT_PAGE_SIZE; /* for redzone */
ctx_obj = i915_gem_object_create_shmem(engine->i915, context_size);
if (IS_ERR(ctx_obj))
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index 6fbc72bc290e..0d3afbf4d4dc 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -5,6 +5,7 @@
*/
#include "i915_selftest.h"
+#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "gem/selftests/mock_context.h"
@@ -64,6 +65,137 @@ static int context_sync(struct intel_context *ce)
return err;
}
+static int __live_context_size(struct intel_engine_cs *engine,
+ struct i915_gem_context *fixme)
+{
+ struct intel_context *ce;
+ struct i915_request *rq;
+ void *vaddr;
+ int err;
+
+ ce = intel_context_create(fixme, engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ err = intel_context_pin(ce);
+ if (err)
+ goto err;
+
+ vaddr = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(engine->i915));
+ if (IS_ERR(vaddr)) {
+ err = PTR_ERR(vaddr);
+ intel_context_unpin(ce);
+ goto err;
+ }
+
+ if (HAS_EXECLISTS(engine->i915))
+ vaddr += LRC_HEADER_PAGES * PAGE_SIZE;
+
+ vaddr += engine->context_size - I915_GTT_PAGE_SIZE;
+ memset(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE);
+
+ rq = intel_context_create_request(ce);
+ intel_context_unpin(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_unpin;
+ }
+
+ err = request_sync(rq);
+ if (err)
+ goto err_unpin;
+
+ /* Force the context switch */
+ rq = i915_request_create(engine->kernel_context);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_unpin;
+ }
+ err = request_sync(rq);
+ if (err)
+ goto err_unpin;
+
+ if (memchr_inv(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE)) {
+ pr_err("%s context overwrote trailing red-zone!", engine->name);
+ err = -EINVAL;
+ }
+
+err_unpin:
+ i915_gem_object_unpin_map(ce->state->obj);
+err:
+ intel_context_put(ce);
+ return err;
+}
+
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Switch obj->mm.lock lockdep annotations on its head
== Series Details == Series: drm/i915: Switch obj->mm.lock lockdep annotations on its head URL : https://patchwork.freedesktop.org/series/65326/ State : warning == Summary == $ dim checkpatch origin/drm-tip d55e4cd434cc drm/i915: Switch obj->mm.lock lockdep annotations on its head -:91: CHECK:LINE_SPACING: Please don't use multiple blank lines #91: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.c:64: + + -:116: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #116: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.h:287: +* struct_mutex in the entire system. */ -:306: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 1 checks, 189 lines checked ___ 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: Extract intel_frontbuffer active tracking
== Series Details == Series: drm/i915: Extract intel_frontbuffer active tracking URL : https://patchwork.freedesktop.org/series/65289/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6715_full -> Patchwork_14045_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14045_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14045_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_14045_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live_execlists: - shard-skl: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6715/shard-skl1/igt@i915_selftest@live_execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14045/shard-skl6/igt@i915_selftest@live_execlists.html Known issues Here are the changes found in Patchwork_14045_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-skl: [PASS][3] -> [FAIL][4] ([fdo#109661]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6715/shard-skl7/igt@gem_...@reset-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14045/shard-skl6/igt@gem_...@reset-stress.html * igt@gem_exec_schedule@preempt-queue-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6715/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14045/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd.html * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +13 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6715/shard-iclb2/igt@gem_exec_sched...@promotion-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14045/shard-iclb5/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_linear_blits@normal: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103927]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6715/shard-apl7/igt@gem_linear_bl...@normal.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14045/shard-apl1/igt@gem_linear_bl...@normal.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([fdo#108686]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6715/shard-glk5/igt@gem_tiled_swapp...@non-threaded.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14045/shard-glk2/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] / [fdo#108840]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6715/shard-iclb6/igt@i915_pm_...@system-suspend-modeset.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14045/shard-iclb2/igt@i915_pm_...@system-suspend-modeset.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6715/shard-apl7/igt@kms_cursor_...@pipe-b-cursor-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14045/shard-apl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][17] -> [FAIL][18] ([fdo#105767]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6715/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14045/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#102670]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6715/shard-skl9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14045/shard-skl5/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) +6 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6715/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [22]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Add explicit DISABLED state for firmware (rev3)
== Series Details == Series: drm/i915/uc: Add explicit DISABLED state for firmware (rev3) URL : https://patchwork.freedesktop.org/series/65278/ State : success == Summary == CI Bug Log - changes from CI_DRM_6720 -> Patchwork_14059 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14059/ Known issues Here are the changes found in Patchwork_14059 that come from known issues: ### IGT changes ### Issues hit * igt@gem_close_race@basic-process: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u3/igt@gem_close_r...@basic-process.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14059/fi-icl-u3/igt@gem_close_r...@basic-process.html * igt@i915_module_load@reload: - fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-blb-e6850/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14059/fi-blb-e6850/igt@i915_module_l...@reload.html Possible fixes * igt@i915_module_load@reload: - fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u3/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14059/fi-icl-u3/igt@i915_module_l...@reload.html * igt@i915_selftest@live_execlists: - fi-skl-gvtdvm: [DMESG-FAIL][7] ([fdo#08]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14059/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html * igt@i915_selftest@live_hangcheck: - fi-icl-u2: [INCOMPLETE][9] ([fdo#107713] / [fdo#108569]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u2/igt@i915_selftest@live_hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14059/fi-icl-u2/igt@i915_selftest@live_hangcheck.html * igt@i915_selftest@live_mman: - fi-bsw-kefka: [DMESG-WARN][11] ([fdo#111373]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-bsw-kefka/igt@i915_selftest@live_mman.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14059/fi-bsw-kefka/igt@i915_selftest@live_mman.html Warnings * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][13] ([fdo#109483]) -> [FAIL][14] ([fdo#111407]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14059/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483 [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08 [fdo#111373]: https://bugs.freedesktop.org/show_bug.cgi?id=111373 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 Participating hosts (54 -> 46) -- Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6720 -> Patchwork_14059 CI-20190529: 20190529 CI_DRM_6720: 7d0da9a1f86471d256afbc80f2cfa82e3aafa8ac @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14059: 10831b03c8925dc29d668245735ee21285d89d1f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 10831b03c892 drm/i915/uc: Add explicit DISABLED state for firmware == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14059/ ___ 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/execlists: Lift process_csb() out of the irq-off spinlock
== Series Details ==
Series: drm/i915/execlists: Lift process_csb() out of the irq-off spinlock
URL : https://patchwork.freedesktop.org/series/65321/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6720 -> Patchwork_14058
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14058/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14058:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_chamelium@hdmi-hpd-fast:
- {fi-icl-u4}:[FAIL][1] ([fdo#111045]) -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14058/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
Known issues
Here are the changes found in Patchwork_14058 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u3/igt@debugfs_test@read_all_entries.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14058/fi-icl-u3/igt@debugfs_test@read_all_entries.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [PASS][5] -> [INCOMPLETE][6] ([fdo#107718])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-blb-e6850/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14058/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [PASS][7] -> [FAIL][8] ([fdo#110627])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14058/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
Possible fixes
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u3/igt@i915_module_l...@reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14058/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][11] ([fdo#08]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14058/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-u2: [INCOMPLETE][13] ([fdo#107713] / [fdo#108569]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14058/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
* igt@i915_selftest@live_mman:
- fi-bsw-kefka: [DMESG-WARN][15] ([fdo#111373]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-bsw-kefka/igt@i915_selftest@live_mman.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14058/fi-bsw-kefka/igt@i915_selftest@live_mman.html
* igt@kms_chamelium@dp-edid-read:
- {fi-icl-u4}:[FAIL][17] ([fdo#111045]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u4/igt@kms_chamel...@dp-edid-read.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14058/fi-icl-u4/igt@kms_chamel...@dp-edid-read.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][19] ([fdo#109483]) -> [FAIL][20] ([fdo#111407])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6720/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14058/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#110627]: https://bugs.freedesktop.org/show_bug.cgi?id=110627
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111373]: https://bugs.freedesktop.org/show_bug.cgi?id=111373
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Check the context size
Quoting Daniele Ceraolo Spurio (2019-08-16 19:43:47) > > > On 8/16/19 10:58 AM, Chris Wilson wrote: > > Add a redzone to our context image and check the HW does not write into > > after a context save, to verify that we have the correct context size. > > (This does vary with feature bits, so test with a live setup that should > > match how we run userspace.) > > > > On newer gens the data saved during the ctx switch is variable, based on > the type of switch and the current state of the HW, e.g. some state is > only saved during a preemption, and the ctx layout is compressed > accordingly. We'd need the test to generate the maximum possible size > (and I have no idea which usage case produces that), but I don't think > that'd scale well from gen to gen. I'd take this as a starting point, and we can definitely generate preemption events easily etc -- it's only when it start depending on state set by userspace do we run into logistical problems (I can only dread encountering such a bug in the wild). So v2, add a redzone everywhere and check on context unpinning. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head
Quoting Daniel Vetter (2019-08-16 19:23:36)
> The trouble with having a plain nesting flag for locks which do not
> naturally nest (unlike block devices and their partitions, which is
> the original motivation for nesting levels) is that lockdep will
> never spot a true deadlock if you screw up.
>
> This patch is an attempt at trying better, by highlighting a bit more
> the actual nature of the nesting that's going on. Essentially we have
> two kinds of objects:
>
> - objects without pages allocated, which cannot be on any lru and are
> hence inaccessible to the shrinker.
>
> - objects which have pages allocated, which are on an lru, and which
> the shrinker can decide to throw out.
>
> For the former type of object, memory allcoations while holding
> obj->mm.lock are permissible. For the latter they are not. And
> get/put_pages transitions between the two types of objects.
>
> This is still not entirely fool-proof since the rules might chance.
> But as long as we run such a code ever at runtime lockdep should be
> able to observe the inconsistency and complain (like with any other
> lockdep class that we've split up in multiple classes). But there are
> a few clear benefits:
>
> - We can drop the nesting flag parameter from
> __i915_gem_object_put_pages, because that function by definition is
> never going allocate memory, and calling it on an object which
> doesn't have its pages allocated would be a bug.
>
> - We strictly catch more bugs, since there's not only one place in the
> entire tree which is annotated with the special class. All the
> other places that had explicit lockdep nesting annotations we're now
> going to leave up to lockdep again.
>
> - Specifically this catches stuff like calling get_pages from
> put_pages (which isn't really a good idea, if we can call put_pages
> so could the shrinker). I've seen patches do exactly that.
>
> Of course I fully expect CI will show me for the fool I am with this
> one here :-)
>
> v2: There can only be one (lockdep only has a cache for the first
> subclass, not for deeper ones, and we don't want to make these locks
> even slower). Still separate enums for better documentation.
>
> Real fix: don forget about phys objs and pin_map(), and fix the
> shrinker to have the right annotations ... silly me.
>
> v3: Forgot usertptr too ...
>
> v4: Improve comment for pages_pin_count, drop the IMPORTANT comment
> and instead prime lockdep (Chris).
>
> Cc: Chris Wilson
> Cc: "Tang, CQ"
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 13 -
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 16 +---
> drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 6 +-
> drivers/gpu/drm/i915/gem/i915_gem_pages.c| 9 -
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 5 ++---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 ++--
> drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++--
> 8 files changed, 45 insertions(+), 22 deletions(-)
static inline int __must_check
i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
{
might_lock(>mm.lock);
if (atomic_inc_not_zero(>mm.pages_pin_count))
return 0;
return __i915_gem_object_get_pages(obj);
}
is now testing the wrong lock class.
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 3929c3a6b281..d01258b175f5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -22,6 +22,8 @@
> *
> */
>
> +#include
> +
> #include "display/intel_frontbuffer.h"
> #include "gt/intel_gt.h"
> #include "i915_drv.h"
> @@ -61,6 +63,15 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
> {
> mutex_init(>mm.lock);
>
> + if (IS_ENABLED(CONFIG_LOCKDEP)) {
> + mutex_lock_nested(>mm.lock, I915_MM_GET_PAGES);
> + fs_reclaim_acquire(GFP_KERNEL);
> + might_lock(>mm.lock);
> + fs_reclaim_release(GFP_KERNEL);
> + mutex_unlock(>mm.lock);
> + }
This is very powerful and sells a lot of churn.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Check the context size
On 8/16/19 10:58 AM, Chris Wilson wrote:
Add a redzone to our context image and check the HW does not write into
after a context save, to verify that we have the correct context size.
(This does vary with feature bits, so test with a live setup that should
match how we run userspace.)
On newer gens the data saved during the ctx switch is variable, based on
the type of switch and the current state of the HW, e.g. some state is
only saved during a preemption, and the ctx layout is compressed
accordingly. We'd need the test to generate the maximum possible size
(and I have no idea which usage case produces that), but I don't think
that'd scale well from gen to gen.
Daniele
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/selftest_context.c | 133 +
1 file changed, 133 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index 6fbc72bc290e..69f2233104f1 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -5,6 +5,7 @@
*/
#include "i915_selftest.h"
+#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "gem/selftests/mock_context.h"
@@ -64,6 +65,137 @@ static int context_sync(struct intel_context *ce)
return err;
}
+static int __live_context_size(struct intel_engine_cs *engine,
+ struct i915_gem_context *fixme)
+{
+ struct intel_context *ce;
+ struct i915_request *rq;
+ void *vaddr;
+ int err;
+
+ ce = intel_context_create(fixme, engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ err = intel_context_pin(ce);
+ if (err)
+ goto err;
+
+ vaddr = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(engine->i915));
+ if (IS_ERR(vaddr)) {
+ err = PTR_ERR(vaddr);
+ intel_context_unpin(ce);
+ goto err;
+ }
+
+ if (HAS_EXECLISTS(engine->i915))
+ vaddr += LRC_HEADER_PAGES * PAGE_SIZE;
+
+ vaddr += engine->context_size - I915_GTT_PAGE_SIZE;
+ memset(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE);
+
+ rq = intel_context_create_request(ce);
+ intel_context_unpin(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_unpin;
+ }
+
+ err = request_sync(rq);
+ if (err)
+ goto err_unpin;
+
+ /* Force the context switch */
+ rq = i915_request_create(engine->kernel_context);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_unpin;
+ }
+ err = request_sync(rq);
+ if (err)
+ goto err_unpin;
+
+ if (memchr_inv(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE)) {
+ pr_err("%s context overwrote trailing red-zone!", engine->name);
+ err = -EINVAL;
+ }
+
+err_unpin:
+ i915_gem_object_unpin_map(ce->state->obj);
+err:
+ intel_context_put(ce);
+ return err;
+}
+
+static int live_context_size(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *fixme;
+ enum intel_engine_id id;
+ struct drm_file *file;
+ int err = 0;
+
+ /*
+* Check that are context sizes are correct by seeing if the
+* HW tries to write past the end of one.
+*/
+
+ file = mock_file(gt->i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(>i915->drm.struct_mutex);
+
+ fixme = live_context(gt->i915, file);
+ if (IS_ERR(fixme)) {
+ err = PTR_ERR(fixme);
+ goto unlock;
+ }
+
+ for_each_engine(engine, gt->i915, id) {
+ struct {
+ struct drm_i915_gem_object *state;
+ void *pinned;
+ } saved;
+
+ if (!engine->context_size)
+ continue;
+
+ intel_engine_pm_get(engine);
+
+ /*
+* Hide the old default state -- we lie about the context size
+* and get confused when the default state is smaller than
+* expected. For our do nothing request, inheriting the
+* active state is sufficient, we are only checking that we
+* don't use more than we planned.
+*/
+ saved.state = fetch_and_zero(>default_state);
+ saved.pinned = fetch_and_zero(>pinned_default_state);
+
+ engine->context_size += I915_GTT_PAGE_SIZE;
+
+ err = __live_context_size(engine, fixme);
+
+ engine->context_size -= I915_GTT_PAGE_SIZE;
+
+ engine->pinned_default_state = saved.pinned;
+ engine->default_state = saved.state;
+
+
Re: [Intel-gfx] [v3] drm/dp/dsc: Add Support for all BPCs supported by TGL
On Thu, Aug 15, 2019 at 01:54:20PM -0700, Anusha Srivatsa wrote:
> DSC engine on ICL supports only 8 and 10 BPC as the input
> BPC. But DSC engine in TGL supports 8, 10 and 12 BPC.
> Add 12 BPC support for DSC while calculating compression
> configuration.
>
> v2: Remove the separate define TGL_DP_DSC_MAX_SUPPORTED_BPC
> and use the value directly.(More such defines can be removed
> as part of future patches). (Ville)
>
> v3: Use values directly instead of accessing the defines
> everytime for min and max DSC BPC.
>
> Cc: Ville Syrjälä
> Cc: Manasi Navare
> Signed-off-by: Anusha Srivatsa
Looks good to me,
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4884c87c8ed7..f9d2438d7da9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -70,8 +70,6 @@
>
> /* DP DSC small joiner has 2 FIFOs each of 640 x 6 bytes */
> #define DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER 61440
> -#define DP_DSC_MIN_SUPPORTED_BPC 8
> -#define DP_DSC_MAX_SUPPORTED_BPC 10
>
> /* DP DSC throughput values used for slice count calculations KPixels/s */
> #define DP_DSC_PEAK_PIXEL_RATE 272
> @@ -1915,11 +1913,17 @@ static int intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> if (!intel_dp_supports_dsc(intel_dp, pipe_config))
> return -EINVAL;
>
> - dsc_max_bpc = min_t(u8, DP_DSC_MAX_SUPPORTED_BPC,
> - conn_state->max_requested_bpc);
> + /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
> + if (INTEL_GEN(dev_priv) >= 12)
> + dsc_max_bpc = min_t(u8, 12, conn_state->max_requested_bpc);
> + else
> + dsc_max_bpc = min_t(u8, 10,
> + conn_state->max_requested_bpc);
>
> pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, dsc_max_bpc);
> - if (pipe_bpp < DP_DSC_MIN_SUPPORTED_BPC * 3) {
> +
> + /* Min Input BPC for ICL+ is 8 */
> + if (pipe_bpp < 8 * 3) {
> DRM_DEBUG_KMS("No DSC support for less than 8bpc\n");
> return -EINVAL;
> }
> --
> 2.22.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Switch obj->mm.lock lockdep annotations on its head
The trouble with having a plain nesting flag for locks which do not
naturally nest (unlike block devices and their partitions, which is
the original motivation for nesting levels) is that lockdep will
never spot a true deadlock if you screw up.
This patch is an attempt at trying better, by highlighting a bit more
the actual nature of the nesting that's going on. Essentially we have
two kinds of objects:
- objects without pages allocated, which cannot be on any lru and are
hence inaccessible to the shrinker.
- objects which have pages allocated, which are on an lru, and which
the shrinker can decide to throw out.
For the former type of object, memory allcoations while holding
obj->mm.lock are permissible. For the latter they are not. And
get/put_pages transitions between the two types of objects.
This is still not entirely fool-proof since the rules might chance.
But as long as we run such a code ever at runtime lockdep should be
able to observe the inconsistency and complain (like with any other
lockdep class that we've split up in multiple classes). But there are
a few clear benefits:
- We can drop the nesting flag parameter from
__i915_gem_object_put_pages, because that function by definition is
never going allocate memory, and calling it on an object which
doesn't have its pages allocated would be a bug.
- We strictly catch more bugs, since there's not only one place in the
entire tree which is annotated with the special class. All the
other places that had explicit lockdep nesting annotations we're now
going to leave up to lockdep again.
- Specifically this catches stuff like calling get_pages from
put_pages (which isn't really a good idea, if we can call put_pages
so could the shrinker). I've seen patches do exactly that.
Of course I fully expect CI will show me for the fool I am with this
one here :-)
v2: There can only be one (lockdep only has a cache for the first
subclass, not for deeper ones, and we don't want to make these locks
even slower). Still separate enums for better documentation.
Real fix: don forget about phys objs and pin_map(), and fix the
shrinker to have the right annotations ... silly me.
v3: Forgot usertptr too ...
v4: Improve comment for pages_pin_count, drop the IMPORTANT comment
and instead prime lockdep (Chris).
Cc: Chris Wilson
Cc: "Tang, CQ"
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 13 -
drivers/gpu/drm/i915/gem/i915_gem_object.h | 16 +---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c| 9 -
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 5 ++---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 ++--
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 12 ++--
8 files changed, 45 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 3929c3a6b281..d01258b175f5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -22,6 +22,8 @@
*
*/
+#include
+
#include "display/intel_frontbuffer.h"
#include "gt/intel_gt.h"
#include "i915_drv.h"
@@ -61,6 +63,15 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
{
mutex_init(>mm.lock);
+ if (IS_ENABLED(CONFIG_LOCKDEP)) {
+ mutex_lock_nested(>mm.lock, I915_MM_GET_PAGES);
+ fs_reclaim_acquire(GFP_KERNEL);
+ might_lock(>mm.lock);
+ fs_reclaim_release(GFP_KERNEL);
+ mutex_unlock(>mm.lock);
+ }
+
+
spin_lock_init(>vma.lock);
INIT_LIST_HEAD(>vma.list);
@@ -191,7 +202,7 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
GEM_BUG_ON(!list_empty(>lut_list));
atomic_set(>mm.pages_pin_count, 0);
- __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
+ __i915_gem_object_put_pages(obj);
GEM_BUG_ON(i915_gem_object_has_pages(obj));
bitmap_free(obj->bit_17);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3714cf234d64..5ce511ca7fa8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -281,11 +281,21 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object
*obj)
enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
I915_MM_NORMAL = 0,
- I915_MM_SHRINKER /* called "recursively" from direct-reclaim-esque */
+ /*
+* Only used by struct_mutex, when called "recursively" from
+* direct-reclaim-esque. Safe because there is only every one
+* struct_mutex in the entire system. */
+ I915_MM_SHRINKER = 1,
+
Re: [Intel-gfx] [PATCH v3] drm/i915/uc: Add explicit DISABLED state for firmware
Quoting Michal Wajdeczko (2019-08-16 18:51:30)
> We really need to have separate NOT_SUPPORTED state (for
> lack of hardware support) and DISABLED state (to indicate
> user decision) as we will have to take special steps even
> if GuC firmware is now disabled but hardware exists and
> could have been previously used.
Could you give a quick run down on the transition points?
driver_probe -> UNINIT
uc_probe -> SUPPORTS
uc_init -> ENABLED
> static inline bool intel_guc_is_supported(struct intel_guc *guc)
> {
> - return intel_uc_fw_supported(>fw);
> + return intel_uc_fw_is_supported(>fw);
> +}
> +
> +static inline bool intel_guc_is_enabled(struct intel_guc *guc)
> +{
> + return intel_uc_fw_is_enabled(>fw);
> }
and include it somewhere around here?
I'm finding that overview hard to put together from the patch context.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Check the context size
Add a redzone to our context image and check the HW does not write into
after a context save, to verify that we have the correct context size.
(This does vary with feature bits, so test with a live setup that should
match how we run userspace.)
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/selftest_context.c | 133 +
1 file changed, 133 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index 6fbc72bc290e..69f2233104f1 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -5,6 +5,7 @@
*/
#include "i915_selftest.h"
+#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "gem/selftests/mock_context.h"
@@ -64,6 +65,137 @@ static int context_sync(struct intel_context *ce)
return err;
}
+static int __live_context_size(struct intel_engine_cs *engine,
+ struct i915_gem_context *fixme)
+{
+ struct intel_context *ce;
+ struct i915_request *rq;
+ void *vaddr;
+ int err;
+
+ ce = intel_context_create(fixme, engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ err = intel_context_pin(ce);
+ if (err)
+ goto err;
+
+ vaddr = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(engine->i915));
+ if (IS_ERR(vaddr)) {
+ err = PTR_ERR(vaddr);
+ intel_context_unpin(ce);
+ goto err;
+ }
+
+ if (HAS_EXECLISTS(engine->i915))
+ vaddr += LRC_HEADER_PAGES * PAGE_SIZE;
+
+ vaddr += engine->context_size - I915_GTT_PAGE_SIZE;
+ memset(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE);
+
+ rq = intel_context_create_request(ce);
+ intel_context_unpin(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_unpin;
+ }
+
+ err = request_sync(rq);
+ if (err)
+ goto err_unpin;
+
+ /* Force the context switch */
+ rq = i915_request_create(engine->kernel_context);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_unpin;
+ }
+ err = request_sync(rq);
+ if (err)
+ goto err_unpin;
+
+ if (memchr_inv(vaddr, POISON_INUSE, I915_GTT_PAGE_SIZE)) {
+ pr_err("%s context overwrote trailing red-zone!", engine->name);
+ err = -EINVAL;
+ }
+
+err_unpin:
+ i915_gem_object_unpin_map(ce->state->obj);
+err:
+ intel_context_put(ce);
+ return err;
+}
+
+static int live_context_size(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *fixme;
+ enum intel_engine_id id;
+ struct drm_file *file;
+ int err = 0;
+
+ /*
+* Check that are context sizes are correct by seeing if the
+* HW tries to write past the end of one.
+*/
+
+ file = mock_file(gt->i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(>i915->drm.struct_mutex);
+
+ fixme = live_context(gt->i915, file);
+ if (IS_ERR(fixme)) {
+ err = PTR_ERR(fixme);
+ goto unlock;
+ }
+
+ for_each_engine(engine, gt->i915, id) {
+ struct {
+ struct drm_i915_gem_object *state;
+ void *pinned;
+ } saved;
+
+ if (!engine->context_size)
+ continue;
+
+ intel_engine_pm_get(engine);
+
+ /*
+* Hide the old default state -- we lie about the context size
+* and get confused when the default state is smaller than
+* expected. For our do nothing request, inheriting the
+* active state is sufficient, we are only checking that we
+* don't use more than we planned.
+*/
+ saved.state = fetch_and_zero(>default_state);
+ saved.pinned = fetch_and_zero(>pinned_default_state);
+
+ engine->context_size += I915_GTT_PAGE_SIZE;
+
+ err = __live_context_size(engine, fixme);
+
+ engine->context_size -= I915_GTT_PAGE_SIZE;
+
+ engine->pinned_default_state = saved.pinned;
+ engine->default_state = saved.state;
+
+ intel_engine_pm_put(engine);
+
+ if (err)
+ break;
+ }
+
+unlock:
+ mutex_unlock(>i915->drm.struct_mutex);
+ mock_file_free(gt->i915, file);
+ return err;
+}
+
static int __live_active_context(struct intel_engine_cs *engine,
struct i915_gem_context *fixme)
{
@@ -303,6 +435,7 @@ static int live_remote_context(void *arg)
int
[Intel-gfx] [PATCH v3] drm/i915/uc: Add explicit DISABLED state for firmware
We really need to have separate NOT_SUPPORTED state (for
lack of hardware support) and DISABLED state (to indicate
user decision) as we will have to take special steps even
if GuC firmware is now disabled but hardware exists and
could have been previously used.
v2: fix logic (Chris/CI)
v3: use proper check to avoid probe failure (CI)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 7 -
drivers/gpu/drm/i915/gt/uc/intel_huc.h| 7 -
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 37 ---
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 17 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 +--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 23 ++
drivers/gpu/drm/i915/i915_drv.h | 4 +--
8 files changed, 71 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 4999db965685..2b2f046d3cc3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -154,7 +154,12 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc
*guc, u32 size);
static inline bool intel_guc_is_supported(struct intel_guc *guc)
{
- return intel_uc_fw_supported(>fw);
+ return intel_uc_fw_is_supported(>fw);
+}
+
+static inline bool intel_guc_is_enabled(struct intel_guc *guc)
+{
+ return intel_uc_fw_is_enabled(>fw);
}
static inline bool intel_guc_is_running(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
index f8a4557c8d6d..644c059fe01d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
@@ -38,7 +38,12 @@ static inline int intel_huc_sanitize(struct intel_huc *huc)
static inline bool intel_huc_is_supported(struct intel_huc *huc)
{
- return intel_uc_fw_supported(>fw);
+ return intel_uc_fw_is_supported(>fw);
+}
+
+static inline bool intel_huc_is_enabled(struct intel_huc *huc)
+{
+ return intel_uc_fw_is_enabled(>fw);
}
static inline bool intel_huc_is_authenticated(struct intel_huc *huc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 96feca99322a..74602487ed67 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -35,7 +35,7 @@ void intel_huc_fw_init_early(struct intel_huc *huc)
struct drm_i915_private *i915 = gt->i915;
intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC,
- intel_uc_supports_guc(uc),
+ intel_uc_uses_guc(uc),
INTEL_INFO(i915)->platform, INTEL_REVID(i915));
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 0dc2b0cf4604..449c432dd768 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -45,17 +45,17 @@ static void __confirm_options(struct intel_uc *uc)
DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
"enable_guc=%d (guc:%s submission:%s huc:%s)\n",
i915_modparams.enable_guc,
-yesno(intel_uc_supports_guc(uc)),
-yesno(intel_uc_supports_guc_submission(uc)),
-yesno(intel_uc_supports_huc(uc)));
+yesno(intel_uc_uses_guc(uc)),
+yesno(intel_uc_uses_guc_submission(uc)),
+yesno(intel_uc_uses_huc(uc)));
if (i915_modparams.enable_guc == -1)
return;
if (i915_modparams.enable_guc == 0) {
- GEM_BUG_ON(intel_uc_supports_guc(uc));
- GEM_BUG_ON(intel_uc_supports_guc_submission(uc));
- GEM_BUG_ON(intel_uc_supports_huc(uc));
+ GEM_BUG_ON(intel_uc_uses_guc(uc));
+ GEM_BUG_ON(intel_uc_uses_guc_submission(uc));
+ GEM_BUG_ON(intel_uc_uses_huc(uc));
return;
}
@@ -266,23 +266,23 @@ void intel_uc_fetch_firmwares(struct intel_uc *uc)
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
int err;
- if (!intel_uc_supports_guc(uc))
+ if (!intel_uc_uses_guc(uc))
return;
err = intel_uc_fw_fetch(>guc.fw, i915);
if (err)
return;
- if (intel_uc_supports_huc(uc))
+ if (intel_uc_uses_huc(uc))
intel_uc_fw_fetch(>huc.fw, i915);
}
void intel_uc_cleanup_firmwares(struct intel_uc *uc)
{
- if (!intel_uc_supports_guc(uc))
+ if (!intel_uc_uses_guc(uc))
return;
- if (intel_uc_supports_huc(uc))
+ if (intel_uc_uses_huc(uc))
intel_uc_fw_cleanup_fetch(>huc.fw);
Re: [Intel-gfx] [PATCH] Revert "nvme-pci: use host managed power state for suspend"
On Fri, Aug 16, 2019 at 6:38 AM Christoph Hellwig wrote: > On Fri, Aug 16, 2019 at 01:30:29PM +0100, Chris Wilson wrote: > > Quoting Christoph Hellwig (2019-08-16 13:26:44) > > > Please, report the actual problem. Blindly reverting a patch without > > > even an explanation of your regressions is not the way to do it. > > > > As stated, the system doesn't suspend. > > > > If you would like to wait, you will get test results from our CI > > giving the current failed state and the outcome of the patch. > > Platform type, SSD vendor and type, firmware version? Also not a fan of knee-jerk reverts. Even if it may turn out to be necessary, let's at least start with a bug report for an opportunity to fix first! Could you please try Rafael's solution? These two commits here: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=xps13-9380-20190812=accd2dd72c8f087441d725dd916688171519e4e6 https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=xps13-9380-20190812=4eaefe8c621c6195c91044396ed8060c179f7aae ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Some more display uncore prep work
== Series Details == Series: Some more display uncore prep work URL : https://patchwork.freedesktop.org/series/65281/ State : success == Summary == CI Bug Log - changes from CI_DRM_6714_full -> Patchwork_14043_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14043_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-apl4/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb6/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb8/igt@gem_exec_sched...@preempt-queue-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd.html * igt@gem_exec_schedule@preempt-queue-chain-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +10 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb2/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-iclb6/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-snb5/igt@i915_pm_rc6_reside...@rc6-accuracy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-snb1/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_cursor_crc@pipe-c-cursor-128x128-random: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#103232]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-skl8/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-iclb8/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_plane@pixel-format-pipe-b-planes: - shard-glk: [PASS][17] -> [INCOMPLETE][18] ([fdo#103359] / [k.org#198133]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-glk5/igt@kms_pl...@pixel-format-pipe-b-planes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-glk2/igt@kms_pl...@pixel-format-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb2/igt@kms_psr2...@frontbuffer.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-iclb1/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#108341]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb6/igt@kms_psr@no_drrs.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14043/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][25] ->
[Intel-gfx] [CI] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock
If we only call process_csb() from the tasklet, though we lose the
ability to bypass ksoftirqd interrupt processing on direct submission
paths, we can push it out of the irq-off spinlock.
The penalty is that we then allow schedule_out to be called concurrently
with schedule_in requiring us to handle the usage count (baked into the
pointer itself) atomically.
As we do kick the tasklets (via local_bh_enable()) after our submission,
there is a possibility there to see if we can pull the local softirq
processing back from the ksoftirqd.
v2: Store the 'switch_priority_hint' on submission, so that we can
safely check during process_csb().
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 136 +++---
drivers/gpu/drm/i915/i915_utils.h | 20 ++-
5 files changed, 108 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 616f3f9a6825..bf9cedfccbf0 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -41,9 +41,7 @@ struct intel_context {
struct intel_engine_cs *engine;
struct intel_engine_cs *inflight;
#define intel_context_inflight(ce) ptr_mask_bits((ce)->inflight, 2)
-#define intel_context_inflight_count(ce) ptr_unmask_bits((ce)->inflight, 2)
-#define intel_context_inflight_inc(ce) ptr_count_inc(&(ce)->inflight)
-#define intel_context_inflight_dec(ce) ptr_count_dec(&(ce)->inflight)
+#define intel_context_inflight_count(ce) ptr_unmask_bits((ce)->inflight, 2)
struct i915_address_space *vm;
struct i915_gem_context *gem_context;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 957f27a2ec97..ba457c1c7dc0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1459,7 +1459,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
for (port = execlists->pending; (rq = *port); port++) {
/* Exclude any contexts already counted in active */
- if (intel_context_inflight_count(rq->hw_context) == 1)
+ if (!intel_context_inflight_count(rq->hw_context))
engine->stats.active++;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 9965a32601d6..5441aa9cb863 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -204,6 +204,16 @@ struct intel_engine_execlists {
*/
unsigned int port_mask;
+ /**
+* @switch_priority_hint: Second context priority.
+*
+* We submit multiple contexts to the HW simultaneously and would
+* like to occasionally switch between them to emulate timeslicing.
+* To know when timeslicing is suitable, we track the priority of
+* the context submitted second.
+*/
+ int switch_priority_hint;
+
/**
* @queue_priority_hint: Highest pending priority.
*
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e9863f4d826b..2978cf16fb9b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -547,27 +547,39 @@ execlists_context_status_change(struct i915_request *rq,
unsigned long status)
status, rq);
}
+static inline struct intel_engine_cs *
+__execlists_schedule_in(struct i915_request *rq)
+{
+ struct intel_engine_cs * const engine = rq->engine;
+ struct intel_context * const ce = rq->hw_context;
+
+ intel_context_get(ce);
+
+ intel_gt_pm_get(engine->gt);
+ execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
+ intel_engine_context_in(engine);
+
+ return engine;
+}
+
static inline struct i915_request *
execlists_schedule_in(struct i915_request *rq, int idx)
{
- struct intel_context *ce = rq->hw_context;
- int count;
+ struct intel_context * const ce = rq->hw_context;
+ struct intel_engine_cs *old;
+ GEM_BUG_ON(!intel_engine_pm_is_awake(rq->engine));
trace_i915_request_in(rq, idx);
- count = intel_context_inflight_count(ce);
- if (!count) {
- intel_context_get(ce);
- ce->inflight = rq->engine;
-
- intel_gt_pm_get(ce->inflight->gt);
- execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
- intel_engine_context_in(ce->inflight);
- }
+ old = READ_ONCE(ce->inflight);
+ do {
+
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/gt: Mark context->active_count as protected by timeline->mutex
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Mark context->active_count
as protected by timeline->mutex
URL : https://patchwork.freedesktop.org/series/65307/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6719 -> Patchwork_14056
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14056/
Known issues
Here are the changes found in Patchwork_14056 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_param@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6719/fi-icl-u3/igt@gem_ctx_pa...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14056/fi-icl-u3/igt@gem_ctx_pa...@basic.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#08])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6719/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14056/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
Possible fixes
* igt@gem_ctx_exec@basic:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6719/fi-icl-u3/igt@gem_ctx_e...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14056/fi-icl-u3/igt@gem_ctx_e...@basic.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-guc}: [FAIL][7] ([fdo#103167]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6719/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14056/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
Participating hosts (52 -> 46)
--
Additional (1): fi-bxt-dsi
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6719 -> Patchwork_14056
CI-20190529: 20190529
CI_DRM_6719: c84d7192c40db5b0d1c1164abeeefa5efe17c5cd @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14056: 85a514bc4d751a6f4017c1e5f17523245ebd87d9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
85a514bc4d75 drm/i915: Markup expected timeline locks for i915_active
7ba1a4495678 drm/i915/gt: Mark context->active_count as protected by
timeline->mutex
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14056/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "nvme-pci: use host managed power state for suspend"
== Series Details == Series: Revert "nvme-pci: use host managed power state for suspend" URL : https://patchwork.freedesktop.org/series/65309/ State : failure == Summary == Applying: Revert "nvme-pci: use host managed power state for suspend" Using index info to reconstruct a base tree... M drivers/nvme/host/pci.c Falling back to patching base and 3-way merge... Auto-merging drivers/nvme/host/pci.c CONFLICT (content): Merge conflict in drivers/nvme/host/pci.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 Revert "nvme-pci: use host managed power state for suspend" When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Add Wa_1604278689:icl,ehl
Quoting Matt Roper (2019-08-16 17:29:09)
> On Fri, Aug 16, 2019 at 08:07:18AM +0100, Chris Wilson wrote:
> > Quoting Patchwork (2019-08-16 00:52:20)
> > > Possible regressions
> > >
> > > * igt@i915_selftest@live_hangcheck:
> > > - fi-icl-u3: [PASS][1] -> [DMESG-FAIL][2]
> > >[1]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
> > >[2]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
> > > - {fi-icl-dsi}: [PASS][3] -> [DMESG-FAIL][4]
> > >[3]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
> > >[4]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
> > > - {fi-icl-u4}:[PASS][5] -> [DMESG-FAIL][6]
> > >[5]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u4/igt@i915_selftest@live_hangcheck.html
> > >[6]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-u4/igt@i915_selftest@live_hangcheck.html
> >
> > All icl machines suffering a similar failure to reset an engine (not
> > rcs!). We haven't seen that before, so it does look very suspicious.
> > -Chris
>
> Hmm. So for a render engine register that's saved/restored as part of
> the context, is there somewhere else I should be setting this value? My
> understanding was that the items added in *_ctx_workarounds_init only
> applied to the render engine (since __intel_engine_init_ctx_wa bails out
> for other engine classes), yet it seems it's the BCS engine that's
> failing to reset with this patch?. If I just I915_WRITE to this
> register, won't the value only apply to whichever context is currently
> executing on the RCS engine and be lost when other contexts switch in?
The magic is in the ordering. If you put it in the gt_workarounds, it
gets applied before we record the default context image -- and so it
gets copied into all subsequent contexts.
The only reason why we still have ctx_workarounds is that some registers
had to be written via CS, and it's easy for us to apply the rule "if the
spec says it is a context register, put it in the ctx_workarounds". We
also use that to determine whether to use a SRM or mmio verification.
At the end of the day, whatever works :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with drm/i915/execlists: Lift process_csb() out of the irq-off spinlock (rev2)
== Series Details ==
Series: series starting with drm/i915/execlists: Lift process_csb() out of the
irq-off spinlock (rev2)
URL : https://patchwork.freedesktop.org/series/65294/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6719 -> Patchwork_14055
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14055 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14055, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14055/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14055:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_blt:
- fi-bdw-gvtdvm: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6719/fi-bdw-gvtdvm/igt@i915_selftest@live_blt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14055/fi-bdw-gvtdvm/igt@i915_selftest@live_blt.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-apl-guc: [PASS][3] -> [DMESG-WARN][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6719/fi-apl-guc/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14055/fi-apl-guc/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Known issues
Here are the changes found in Patchwork_14055 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][5] -> [FAIL][6] ([fdo#108511])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6719/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14055/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-apl-guc: [PASS][7] -> [DMESG-WARN][8] ([fdo#103558])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6719/fi-apl-guc/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14055/fi-apl-guc/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-apl-guc: [PASS][9] -> [DMESG-WARN][10] ([fdo#103558] /
[fdo#105602])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6719/fi-apl-guc/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14055/fi-apl-guc/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
Possible fixes
* igt@gem_ctx_exec@basic:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6719/fi-icl-u3/igt@gem_ctx_e...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14055/fi-icl-u3/igt@gem_ctx_e...@basic.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-guc}: [FAIL][13] ([fdo#103167]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6719/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14055/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
Participating hosts (52 -> 46)
--
Additional (1): fi-bxt-dsi
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6719 -> Patchwork_14055
CI-20190529: 20190529
CI_DRM_6719: c84d7192c40db5b0d1c1164abeeefa5efe17c5cd @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14055: f078e08d7958f65b1b2fd74b56a70ce1187a4426 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f078e08d7958 drm/i915: Markup expected timeline locks for i915_active
783265de90c7 drm/i915/gt: Mark context->active_count as protected by
timeline->mutex
62875a3f6df9 drm/i915/execlists: Lift process_csb() out of the irq-off spinlock
== Logs ==
For more details see:
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri, Aug 16, 2019 at 4:38 PM Jason Gunthorpe wrote: > > On Fri, Aug 16, 2019 at 04:11:34PM +0200, Daniel Vetter wrote: > > Also, aside from this patch (which is prep for the next) and some > > simple reordering conflicts they're all independent. So if there's no > > way to paint this bikeshed here (technicolor perhaps?) then I'd like > > to get at least the others considered. > > Sure, I think for conflict avoidance reasons I'm probably taking > mmu_notifier stuff via hmm.git, so: > > - Andrew had a minor remark on #1, I am ambivalent and would take it > as-is. Your decision if you want to respin. I like mine better, see also the reply from Ralph Campbell. > - #2/#3 is this issue, I would stand by the preempt_disable/etc path > Our situation matches yours, debug tests run lockdep/etc. Since Michal requested the current flavour I think we need spin a bit more on these here. I guess I'll just rebase them to the end so they're not holding up the others. > - #4 I like a lot, except the map should enclose range_end too, > this can be done after the mm_has_notifiers inside the > __mmu_notifier function To make sure I get this right: The same lockdep context, but also wrapped around invalidate_range_end? From my understanding of pte zapping that makes sense, but I'm definitely not well-versed enough for that. > Can you respin? Will do. > I will propose preloading the map in another patch > - #5 is already applied in -rc Yup, I'll drop that one. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Add Wa_1604278689:icl,ehl
On Fri, Aug 16, 2019 at 08:07:18AM +0100, Chris Wilson wrote:
> Quoting Patchwork (2019-08-16 00:52:20)
> > Possible regressions
> >
> > * igt@i915_selftest@live_hangcheck:
> > - fi-icl-u3: [PASS][1] -> [DMESG-FAIL][2]
> >[1]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
> >[2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
> > - {fi-icl-dsi}: [PASS][3] -> [DMESG-FAIL][4]
> >[3]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
> >[4]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
> > - {fi-icl-u4}:[PASS][5] -> [DMESG-FAIL][6]
> >[5]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u4/igt@i915_selftest@live_hangcheck.html
> >[6]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-u4/igt@i915_selftest@live_hangcheck.html
>
> All icl machines suffering a similar failure to reset an engine (not
> rcs!). We haven't seen that before, so it does look very suspicious.
> -Chris
Hmm. So for a render engine register that's saved/restored as part of
the context, is there somewhere else I should be setting this value? My
understanding was that the items added in *_ctx_workarounds_init only
applied to the render engine (since __intel_engine_init_ctx_wa bails out
for other engine classes), yet it seems it's the BCS engine that's
failing to reset with this patch?. If I just I915_WRITE to this
register, won't the value only apply to whichever context is currently
executing on the RCS engine and be lost when other contexts switch in?
Matt
--
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.CHECKPATCH: warning for series starting with drm/i915/execlists: Lift process_csb() out of the irq-off spinlock (rev2)
== Series Details == Series: series starting with drm/i915/execlists: Lift process_csb() out of the irq-off spinlock (rev2) URL : https://patchwork.freedesktop.org/series/65294/ State : warning == Summary == $ dim checkpatch origin/drm-tip 62875a3f6df9 drm/i915/execlists: Lift process_csb() out of the irq-off spinlock 783265de90c7 drm/i915/gt: Mark context->active_count as protected by timeline->mutex f078e08d7958 drm/i915: Markup expected timeline locks for i915_active -:291: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment #291: FILE: drivers/gpu/drm/i915/i915_active_types.h:28: + struct mutex *lock; total: 0 errors, 0 warnings, 1 checks, 242 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for More WOPCM fixes (rev2)
== Series Details == Series: More WOPCM fixes (rev2) URL : https://patchwork.freedesktop.org/series/65263/ State : success == Summary == CI Bug Log - changes from CI_DRM_6714_full -> Patchwork_14039_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14039_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb6/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@deep-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb5/igt@gem_exec_sched...@deep-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-iclb2/igt@gem_exec_sched...@deep-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +15 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb2/igt@gem_exec_sched...@preempt-queue-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-iclb8/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_softpin@noreloc-s3: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / [fdo#109100]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb8/igt@gem_soft...@noreloc-s3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-iclb7/igt@gem_soft...@noreloc-s3.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-snb5/igt@i915_pm_rc6_reside...@rc6-accuracy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-snb2/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([fdo#104108] / [fdo#107807]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-skl9/igt@i915_pm_...@system-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-skl3/igt@i915_pm_...@system-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-128x128-random: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103232]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#104873]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-glk6/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [PASS][17] -> [FAIL][18] ([fdo#105363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-glk9/igt@kms_f...@flip-vs-expired-vblank.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-glk4/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-kbl: [PASS][19] -> [FAIL][20] ([fdo#105363]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-kbl4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-kbl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip_tiling@flip-to-y-tiled: - shard-iclb: [PASS][21] -> [INCOMPLETE][22] ([fdo#107713]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb3/igt@kms_flip_til...@flip-to-y-tiled.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-iclb1/igt@kms_flip_til...@flip-to-y-tiled.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#103167]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14039/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-apl: [PASS][25] ->
[Intel-gfx] ✓ Fi.CI.BAT: success for More WOPCM fixes (rev3)
== Series Details ==
Series: More WOPCM fixes (rev3)
URL : https://patchwork.freedesktop.org/series/65263/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6718 -> Patchwork_14054
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14054/
Known issues
Here are the changes found in Patchwork_14054 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14054/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@double-flink:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14054/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
* igt@i915_selftest@live_hangcheck:
- fi-icl-u2: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] /
[fdo#108569])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14054/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][7] ([fdo#08]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14054/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
Participating hosts (54 -> 46)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6718 -> Patchwork_14054
CI-20190529: 20190529
CI_DRM_6718: b6d542cb2fbbc69487b1e83634395439a8fafa94 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14054: 7aeae2e6239c77c18709c1dea7764c6f9e61cf29 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7aeae2e6239c drm/i915/wopmc: Fix SPDX tag location
1c099f839e49 drm/i915/wopcm: Update error messages
68c77b0f042d drm/i915/wopcm: Try to use already locked WOPCM layout
8c3bd6d75378 drm/i915/wopcm: Check WOPCM layout separately from calculations
b05e96b78b8c drm/i915/uc: Move FW size sanity check back to fetch
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14054/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Introduce i915_reg_types.h
On 8/16/19 2:40 AM, Michal Wajdeczko wrote: On Fri, 16 Aug 2019 03:23:42 +0200, Daniele Ceraolo Spurio wrote: With the introduction of display uncore, we want to categorize registers between display and non-display. To help us getting it right, it will be useful to move the display registers to a new file that can be used without including i915_reg.h. To allow that, move all the basic register type definitions and helpers to i915_reg_types.h and include that instead of i915_reg.h from header files in the driver. We'll then be able to replace i915_reg.h with the new display-only header in display files and make sure the registers are correctly compartmentalized. maybe this split should another way: i915_reg.h = basic typedefs and macros intel_reg.h = register definitions and intel_display_reg.h = display related regs (your goal) intel_guc_reg.h = GuC related regs (we already have that!) then we follow the rule to use i915_ prefix for driver specific code and intel_ prefix for hardware originated definitions Around the code we're using the *_types.h format for the headers with the basic defs, so I'd prefer to stick with that. But I can go with intel_* prefix and rename i915_reg.h to intel_reg.h. Daniele Michal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Dynamically allocate s0ix struct for VLV
On 8/16/19 2:35 AM, Jani Nikula wrote:
On Thu, 15 Aug 2019, Daniele Ceraolo Spurio
wrote:
This is only required for a single platform so no need to reserve the
memory on all of them.
This removes the last direct dependency of i915_drv.h on i915_reg.h
(apart from the i915_reg_t definition).
Signed-off-by: Daniele Ceraolo Spurio
Cc: Imre Deak
Heh, I've already sent a version of this [1], but I don't mind you
finishing the job. Especially because I think it's better to handle the
alloc/free explicitly instead of the way I do it.
D'oh! I completely missed that
I do have some nitpicks on this one though, inline.
[1]
http://patchwork.freedesktop.org/patch/msgid/20190807144939.32123-1-jani.nik...@intel.com
@@ -2137,7 +2228,7 @@ static int i915_pm_restore(struct device *kdev)
*/
static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv)
{
- struct vlv_s0ix_state *s = _priv->vlv_s0ix_state;
+ struct vlv_s0ix_state *s = dev_priv->s0ix_state;
I think I'd now call this function unconditionally, and return early if
(!s). This puts the decision to do this or not in one place only, in
vlv_alloc_s0ix_state(), instead of duplicating the conditions.
ack
int i;
/* GAM 0x4000-0x4770 */
@@ -2147,7 +2238,7 @@ static void vlv_save_gunit_s0ix_state(struct
drm_i915_private *dev_priv)
s->gfx_pend_tlb0 = I915_READ(GEN7_GFX_PEND_TLB0);
s->gfx_pend_tlb1 = I915_READ(GEN7_GFX_PEND_TLB1);
- for (i = 0; i < ARRAY_SIZE(s->lra_limits); i++)
+ for (i = 0; i < GEN7_LRA_LIMITS_REG_NUM; i++)
s->lra_limits[i] = I915_READ(GEN7_LRA_LIMITS(i));
s->media_max_req_count = I915_READ(GEN7_MEDIA_MAX_REQ_COUNT);
@@ -2191,7 +2282,7 @@ static void vlv_save_gunit_s0ix_state(struct
drm_i915_private *dev_priv)
s->pm_imr= I915_READ(GEN6_PMIMR);
s->pm_ier= I915_READ(GEN6_PMIER);
- for (i = 0; i < ARRAY_SIZE(s->gt_scratch); i++)
+ for (i = 0; i < GEN7_GT_SCRATCH_REG_NUM; i++)
s->gt_scratch[i] = I915_READ(GEN7_GT_SCRATCH(i));
The above two hunks are in the wrong patch.
Yup, leftovers from a previous version.
/* GT SA CZ domain, 0x10-0x138124 */
@@ -2218,7 +2309,7 @@ static void vlv_save_gunit_s0ix_state(struct
drm_i915_private *dev_priv)
static void vlv_restore_gunit_s0ix_state(struct drm_i915_private *dev_priv)
{
- struct vlv_s0ix_state *s = _priv->vlv_s0ix_state;
+ struct vlv_s0ix_state *s = dev_priv->s0ix_state;
Early return on !s here as well, and call the function unconditionally.
ok
u32 val;
int i;
@@ -2229,7 +2320,7 @@ static void vlv_restore_gunit_s0ix_state(struct drm_i915_private *dev_priv)
I915_WRITE(GEN7_GFX_PEND_TLB0, s->gfx_pend_tlb0);
I915_WRITE(GEN7_GFX_PEND_TLB1, s->gfx_pend_tlb1);
- for (i = 0; i < ARRAY_SIZE(s->lra_limits); i++)
+ for (i = 0; i < GEN7_LRA_LIMITS_REG_NUM; i++)
I915_WRITE(GEN7_LRA_LIMITS(i), s->lra_limits[i]);
I915_WRITE(GEN7_MEDIA_MAX_REQ_COUNT, s->media_max_req_count);
@@ -2273,7 +2364,7 @@ static void vlv_restore_gunit_s0ix_state(struct
drm_i915_private *dev_priv)
I915_WRITE(GEN6_PMIMR, s->pm_imr);
I915_WRITE(GEN6_PMIER, s->pm_ier);
- for (i = 0; i < ARRAY_SIZE(s->gt_scratch); i++)
+ for (i = 0; i < GEN7_GT_SCRATCH_REG_NUM; i++)
I915_WRITE(GEN7_GT_SCRATCH(i), s->gt_scratch[i]);
The above two hunks are in the wrong patch.
/* GT SA CZ domain, 0x10-0x138124 */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c6722d54ccd5..9b41f2209b69 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -527,68 +527,6 @@ struct i915_suspend_saved_registers {
u16 saveGCDGMBUS;
};
-struct vlv_s0ix_state {
- /* GAM */
- u32 wr_watermark;
- u32 gfx_prio_ctrl;
- u32 arb_mode;
- u32 gfx_pend_tlb0;
- u32 gfx_pend_tlb1;
- u32 lra_limits[GEN7_LRA_LIMITS_REG_NUM];
- u32 media_max_req_count;
- u32 gfx_max_req_count;
- u32 render_hwsp;
- u32 ecochk;
- u32 bsd_hwsp;
- u32 blt_hwsp;
- u32 tlb_rd_addr;
-
- /* MBC */
- u32 g3dctl;
- u32 gsckgctl;
- u32 mbctl;
-
- /* GCP */
- u32 ucgctl1;
- u32 ucgctl3;
- u32 rcgctl1;
- u32 rcgctl2;
- u32 rstctl;
- u32 misccpctl;
-
- /* GPM */
- u32 gfxpause;
- u32 rpdeuhwtc;
- u32 rpdeuc;
- u32 ecobus;
- u32 pwrdwnupctl;
- u32 rp_down_timeout;
- u32 rp_deucsw;
- u32 rcubmabdtmr;
- u32 rcedata;
- u32 spare2gh;
-
- /* Display 1 CZ domain */
- u32 gt_imr;
- u32 gt_ier;
- u32 pm_imr;
- u32 pm_ier;
- u32 gt_scratch[GEN7_GT_SCRATCH_REG_NUM];
-
- /* GT SA CZ domain */
- u32 tilectl;
- u32
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Dynamically allocate s0ix struct for VLV
@@ -2229,7 +2320,7 @@ static void vlv_restore_gunit_s0ix_state(struct
drm_i915_private *dev_priv)
I915_WRITE(GEN7_GFX_PEND_TLB0, s->gfx_pend_tlb0);
I915_WRITE(GEN7_GFX_PEND_TLB1, s->gfx_pend_tlb1);
- for (i = 0; i < ARRAY_SIZE(s->lra_limits); i++)
+ for (i = 0; i < GEN7_LRA_LIMITS_REG_NUM; i++)
why?
Leftover from the first version I had locally where I was trying to
dynamically allocate just the arrays instead of the whole thing. Will
get rid of it.
Daniele
Lucas De Marchi
I915_WRITE(GEN7_LRA_LIMITS(i), s->lra_limits[i]);
I915_WRITE(GEN7_MEDIA_MAX_REQ_COUNT, s->media_max_req_count);
@@ -2273,7 +2364,7 @@ static void vlv_restore_gunit_s0ix_state(struct
drm_i915_private *dev_priv)
I915_WRITE(GEN6_PMIMR, s->pm_imr);
I915_WRITE(GEN6_PMIER, s->pm_ier);
- for (i = 0; i < ARRAY_SIZE(s->gt_scratch); i++)
+ for (i = 0; i < GEN7_GT_SCRATCH_REG_NUM; i++)
I915_WRITE(GEN7_GT_SCRATCH(i), s->gt_scratch[i]);
/* GT SA CZ domain, 0x10-0x138124 */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c6722d54ccd5..9b41f2209b69 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -527,68 +527,6 @@ struct i915_suspend_saved_registers {
u16 saveGCDGMBUS;
};
-struct vlv_s0ix_state {
- /* GAM */
- u32 wr_watermark;
- u32 gfx_prio_ctrl;
- u32 arb_mode;
- u32 gfx_pend_tlb0;
- u32 gfx_pend_tlb1;
- u32 lra_limits[GEN7_LRA_LIMITS_REG_NUM];
- u32 media_max_req_count;
- u32 gfx_max_req_count;
- u32 render_hwsp;
- u32 ecochk;
- u32 bsd_hwsp;
- u32 blt_hwsp;
- u32 tlb_rd_addr;
-
- /* MBC */
- u32 g3dctl;
- u32 gsckgctl;
- u32 mbctl;
-
- /* GCP */
- u32 ucgctl1;
- u32 ucgctl3;
- u32 rcgctl1;
- u32 rcgctl2;
- u32 rstctl;
- u32 misccpctl;
-
- /* GPM */
- u32 gfxpause;
- u32 rpdeuhwtc;
- u32 rpdeuc;
- u32 ecobus;
- u32 pwrdwnupctl;
- u32 rp_down_timeout;
- u32 rp_deucsw;
- u32 rcubmabdtmr;
- u32 rcedata;
- u32 spare2gh;
-
- /* Display 1 CZ domain */
- u32 gt_imr;
- u32 gt_ier;
- u32 pm_imr;
- u32 pm_ier;
- u32 gt_scratch[GEN7_GT_SCRATCH_REG_NUM];
-
- /* GT SA CZ domain */
- u32 tilectl;
- u32 gt_fifoctl;
- u32 gtlc_wake_ctrl;
- u32 gtlc_survive;
- u32 pmwgicz;
-
- /* Display 2 CZ domain */
- u32 gu_ctl0;
- u32 gu_ctl1;
- u32 pcbr;
- u32 clock_gate_dis2;
-};
-
struct intel_rps_ei {
ktime_t ktime;
u32 render_c0;
@@ -1622,7 +1560,7 @@ struct drm_i915_private {
u32 suspend_count;
bool power_domains_suspended;
struct i915_suspend_saved_registers regfile;
- struct vlv_s0ix_state vlv_s0ix_state;
+ void *s0ix_state;
enum {
I915_SAGV_UNKNOWN = 0,
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Move i915_power_well_id out of i915_reg.h
On 8/16/19 8:27 AM, Daniele Ceraolo Spurio wrote:
On 8/15/19 9:52 PM, Lucas De Marchi wrote:
On Thu, Aug 15, 2019 at 6:24 PM Daniele Ceraolo Spurio
wrote:
It has nothing to do with registers, so move it to the more appropriate
intel_display_power.h
Signed-off-by: Daniele Ceraolo Spurio
Cc: Imre Deak
---
.../drm/i915/display/intel_display_power.c | 1 +
.../drm/i915/display/intel_display_power.h | 21 +++
drivers/gpu/drm/i915/display/intel_hdcp.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 21 ---
4 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 374b75602141..1caae2f61216 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -13,6 +13,7 @@
#include "intel_cdclk.h"
#include "intel_combo_phy.h"
#include "intel_csr.h"
+#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_dpio_phy.h"
#include "intel_hotplug.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
b/drivers/gpu/drm/i915/display/intel_display_power.h
index 97f2562fc5d3..a50605b8b1ad 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -92,6 +92,27 @@ enum intel_display_power_domain {
POWER_DOMAIN_NUM,
};
+/*
+ * i915_power_well_id:
+ *
+ * IDs used to look up power wells. Power wells accessed directly
bypassing
+ * the power domains framework must be assigned a unique ID. The
rest of power
+ * wells must be assigned DISP_PW_ID_NONE.
+ */
+enum i915_power_well_id {
+ DISP_PW_ID_NONE,
+
+ VLV_DISP_PW_DISP2D,
+ BXT_DISP_PW_DPIO_CMN_A,
+ VLV_DISP_PW_DPIO_CMN_BC,
+ GLK_DISP_PW_DPIO_CMN_C,
+ CHV_DISP_PW_DPIO_CMN_D,
+ HSW_DISP_PW_GLOBAL,
+ SKL_DISP_PW_MISC_IO,
+ SKL_DISP_PW_1,
+ SKL_DISP_PW_2,
+};
+
#define POWER_DOMAIN_PIPE(pipe) ((pipe) + POWER_DOMAIN_PIPE_A)
#define POWER_DOMAIN_PIPE_PANEL_FITTER(pipe) \
((pipe) + POWER_DOMAIN_PIPE_A_PANEL_FITTER)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index dc4aaec2e04c..0beb954b5318 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -14,6 +14,7 @@
#include
#include "i915_reg.h"
+#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_hdcp.h"
#include "intel_sideband.h"
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 2b7ccebf6550..14165d619175 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1163,27 +1163,6 @@ static inline bool
i915_mmio_reg_valid(i915_reg_t reg)
#define PUNIT_REG_ISPSSPM0 0x39
#define PUNIT_REG_ISPSSPM1 0x3a
-/*
- * i915_power_well_id:
- *
- * IDs used to look up power wells. Power wells accessed directly
bypassing
- * the power domains framework must be assigned a unique ID. The
rest of power
- * wells must be assigned DISP_PW_ID_NONE.
- */
-enum i915_power_well_id {
- DISP_PW_ID_NONE,
-
- VLV_DISP_PW_DISP2D,
- BXT_DISP_PW_DPIO_CMN_A,
- VLV_DISP_PW_DPIO_CMN_BC,
- GLK_DISP_PW_DPIO_CMN_C,
- CHV_DISP_PW_DPIO_CMN_D,
- HSW_DISP_PW_GLOBAL,
- SKL_DISP_PW_MISC_IO,
- SKL_DISP_PW_1,
- SKL_DISP_PW_2,
-};
drivers/gpu/drm/i915/display/intel_hdcp.c also uses this enum, so it
should also include the header
in which it's defined.
That's already done in this patch. Were you thinking of another header?
Sorry, I meant another .c file (I haven't had my coffee yet...)
Daniele
> Daniele
other than that
Reviewed-by: Lucas De Marchi
Lucas De Marchi
-
#define PUNIT_REG_PWRGT_CTRL 0x60
#define PUNIT_REG_PWRGT_STATUS 0x61
#define PUNIT_PWRGT_MASK(pw_idx) (3 << ((pw_idx) * 2))
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Move i915_power_well_id out of i915_reg.h
On 8/15/19 9:52 PM, Lucas De Marchi wrote:
On Thu, Aug 15, 2019 at 6:24 PM Daniele Ceraolo Spurio
wrote:
It has nothing to do with registers, so move it to the more appropriate
intel_display_power.h
Signed-off-by: Daniele Ceraolo Spurio
Cc: Imre Deak
---
.../drm/i915/display/intel_display_power.c| 1 +
.../drm/i915/display/intel_display_power.h| 21 +++
drivers/gpu/drm/i915/display/intel_hdcp.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 21 ---
4 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 374b75602141..1caae2f61216 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -13,6 +13,7 @@
#include "intel_cdclk.h"
#include "intel_combo_phy.h"
#include "intel_csr.h"
+#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_dpio_phy.h"
#include "intel_hotplug.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
b/drivers/gpu/drm/i915/display/intel_display_power.h
index 97f2562fc5d3..a50605b8b1ad 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -92,6 +92,27 @@ enum intel_display_power_domain {
POWER_DOMAIN_NUM,
};
+/*
+ * i915_power_well_id:
+ *
+ * IDs used to look up power wells. Power wells accessed directly bypassing
+ * the power domains framework must be assigned a unique ID. The rest of power
+ * wells must be assigned DISP_PW_ID_NONE.
+ */
+enum i915_power_well_id {
+ DISP_PW_ID_NONE,
+
+ VLV_DISP_PW_DISP2D,
+ BXT_DISP_PW_DPIO_CMN_A,
+ VLV_DISP_PW_DPIO_CMN_BC,
+ GLK_DISP_PW_DPIO_CMN_C,
+ CHV_DISP_PW_DPIO_CMN_D,
+ HSW_DISP_PW_GLOBAL,
+ SKL_DISP_PW_MISC_IO,
+ SKL_DISP_PW_1,
+ SKL_DISP_PW_2,
+};
+
#define POWER_DOMAIN_PIPE(pipe) ((pipe) + POWER_DOMAIN_PIPE_A)
#define POWER_DOMAIN_PIPE_PANEL_FITTER(pipe) \
((pipe) + POWER_DOMAIN_PIPE_A_PANEL_FITTER)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index dc4aaec2e04c..0beb954b5318 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -14,6 +14,7 @@
#include
#include "i915_reg.h"
+#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_hdcp.h"
#include "intel_sideband.h"
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2b7ccebf6550..14165d619175 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1163,27 +1163,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define PUNIT_REG_ISPSSPM0 0x39
#define PUNIT_REG_ISPSSPM1 0x3a
-/*
- * i915_power_well_id:
- *
- * IDs used to look up power wells. Power wells accessed directly bypassing
- * the power domains framework must be assigned a unique ID. The rest of power
- * wells must be assigned DISP_PW_ID_NONE.
- */
-enum i915_power_well_id {
- DISP_PW_ID_NONE,
-
- VLV_DISP_PW_DISP2D,
- BXT_DISP_PW_DPIO_CMN_A,
- VLV_DISP_PW_DPIO_CMN_BC,
- GLK_DISP_PW_DPIO_CMN_C,
- CHV_DISP_PW_DPIO_CMN_D,
- HSW_DISP_PW_GLOBAL,
- SKL_DISP_PW_MISC_IO,
- SKL_DISP_PW_1,
- SKL_DISP_PW_2,
-};
drivers/gpu/drm/i915/display/intel_hdcp.c also uses this enum, so it
should also include the header
in which it's defined.
That's already done in this patch. Were you thinking of another header?
Daniele
other than that
Reviewed-by: Lucas De Marchi
Lucas De Marchi
-
#define PUNIT_REG_PWRGT_CTRL 0x60
#define PUNIT_REG_PWRGT_STATUS 0x61
#define PUNIT_PWRGT_MASK(pw_idx) (3 << ((pw_idx) * 2))
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: disable DDIC
On Fri, Aug 16, 2019 at 3:14 AM Shankar, Uma wrote: > > > > >-Original Message- > >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > >Of Lucas > >De Marchi > >Sent: Thursday, August 15, 2019 5:25 AM > >To: intel-gfx@lists.freedesktop.org > >Subject: [Intel-gfx] [PATCH] drm/i915/tgl: disable DDIC > > > >The current SKUs added for Tiger Lake don't have DDIC hooked up, even though > >it is > >supported by the SoC. The current state for these SKUs is problematic since > >while > >enabling the combo phy, PORT_COMP_DW* return 0x, which is invalid per > >register definition. > > > >During initialization we check what phys are not yet enabled by reading > >PHY_MISC_C > >and try to enable it by toggling the "DE to IO Comp Pwr Down" > >bit. But after that any read to the PORT_COMP_DW* returns invalid results. > >This > >removes the following warning > > > >[56997.634353] Missing case (val == 4294967295) [56997.639241] WARNING: CPU: > >5 > >PID: 768 at drivers/gpu/drm/i915/display/intel_combo_phy.c:54 > >cnl_get_procmon_ref_values+0xc9/0xf0 [i915] [56997.639808] Modules linked in: > >i915(+) prime_numbers x86_pkg_temp_thermal coretemp kvm_intel kvm irqbypass > >crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e [last unloaded: > >prime_numbers] > >[56997.639808] CPU: 5 PID: 768 Comm: insmod Tainted: G U W > >5.2.0- > >demarchi+ #65 > >[56997.639808] Hardware name: Intel Corporation Tiger Lake Client > >Platform/TigerLake U DDR4 SODIMM RVP, BIOS > >TGLSFWI1.R00.2252.A03.1906270154 06/27/2019 [56997.639808] RIP: > >0010:cnl_get_procmon_ref_values+0xc9/0xf0 [i915] [56997.639808] Code: 2c a0 > >85 > >c9 74 e0 81 f9 00 00 00 01 75 09 48 c7 c0 0c a4 2c a0 eb cf 48 c7 c6 3c 3a > >31 a0 48 c7 > >c7 40 3a 31 a0 e8 6b 4d ea e0 <0f> 0b 48 c7 c0 00 a4 2c a0 eb b1 48 c7 c0 24 > >a4 2 c a0 > >eb a8 e8 be [56997.639808] RSP: 0018:c968f8a8 EFLAGS: 00010286 > >[56997.639808] RAX: RBX: 88848fa9 RCX: > > [56997.639808] RDX: 8884a08b5ef8 RSI: 8884a08a6658 > >RDI: [56997.639808] RBP: 0002 R08: > > R09: [56997.639808] R10: > > R11: R12: 88848fa9 [56997.639808] > >R13: R14: 0002 R15: 0006c0162000 > >[56997.639808] FS: 7f61ca3d12c0() GS:8884a088() > >knlGS: [56997.639808] CS: 0010 DS: ES: CR0: > >80050033 [56997.639808] CR2: 7f71be6a92c0 CR3: > >000494750006 CR4: 00760ee0 [56997.639808] PKRU: 5554 > >[56997.639808] Call Trace: > >[56997.639808] cnl_verify_procmon_ref_values+0x36/0xf0 [i915] > >[56997.639808] ? > >rcu_read_lock_sched_held+0x6f/0x80 > >[56997.639808] ? gen11_fwtable_read32+0x257/0x290 [i915] [56997.639808] > >icl_combo_phy_verify_state.part.0+0x22/0xa0 [i915] [56997.639808] > >intel_combo_phy_init+0x17e/0x3e0 [i915] [56997.639808] ? > >icl_display_core_init+0x2c/0x1a0 [i915] [56997.639808] ? > >_raw_spin_unlock_irqrestore+0x4c/0x60 > >[56997.639808] icl_display_core_init+0x34/0x1a0 [i915] [56997.639808] > >intel_power_domains_init_hw+0x200/0x570 [i915] [56997.639808] > >i915_driver_probe+0x103b/0x17e0 [i915] [56997.639808] ? printk+0x53/0x6a > >[56997.639808] i915_pci_probe+0x3b/0x190 [i915] > > > >We may or may not need to change the implementation to account for DDIC being > >available on other SKUs. For now I think the best thing to do is to just > >disable the port. > > This information ideally should be coming from VBT and based on that driver > can take a call > whether to enable the port or not. So is this an interim solution and later > would be dropped, > since there will/may be SKU's with PORT C enabled. > > I feel revocation of this port in VBT should be the right approach, instead > of an interim solution. Ideally yes, but it's better something that works than the ideal solution that doesn't. I wanted to go the VBT route, but it wouldn't work with any machine that I have available. Hence this patch. When/if there's one sku with ddic, hopefully VBT will already be fixed or we may go the route of differentiating by PCI id. Lucas De Marchi > > Regards, > Uma Shankar > > >Cc: José Roberto de Souza > >Signed-off-by: Lucas De Marchi > >--- > > drivers/gpu/drm/i915/display/intel_display.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > >diff --git a/drivers/gpu/drm/i915/display/intel_display.c > >b/drivers/gpu/drm/i915/display/intel_display.c > >index 5b733e38eae3..6c6a5a5f41bb 100644 > >--- a/drivers/gpu/drm/i915/display/intel_display.c > >+++ b/drivers/gpu/drm/i915/display/intel_display.c > >@@ -6683,7 +6683,7 @@ bool intel_phy_is_combo(struct drm_i915_private > >*dev_priv, enum phy phy) > > if (phy == PHY_NONE) > > return false; > > > >- if (IS_ELKHARTLAKE(dev_priv) || INTEL_GEN(dev_priv) >= 12) > >+ if
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri, Aug 16, 2019 at 11:31:45AM -0300, Jason Gunthorpe wrote: > On Fri, Aug 16, 2019 at 02:26:25PM +0200, Michal Hocko wrote: > > On Fri 16-08-19 09:19:06, Jason Gunthorpe wrote: > > > On Fri, Aug 16, 2019 at 10:10:29AM +0200, Michal Hocko wrote: > > > > On Thu 15-08-19 17:13:23, Jason Gunthorpe wrote: > > > > > On Thu, Aug 15, 2019 at 09:35:26PM +0200, Michal Hocko wrote: [...] > > > I would like to inject it into the notifier path as this is very > > > difficult for driver authors to discover and know about, but I'm > > > worried about your false positive remark. > > > > > > I think I understand we can use only GFP_ATOMIC in the notifiers, but > > > we need a strategy to handle OOM to guarentee forward progress. > > > > Your example is from the notifier registration IIUC. > > Yes, that is where this commit hit it.. Triggering this under an > actual notifier to get a lockdep report is hard. > > > Can you pre-allocate before taking locks? Could you point me to some > > examples when the allocation is necessary in the range notifier > > callback? > > Hmm. I took a careful look, I only found mlx5 as obviously allocating > memory: > > mlx5_ib_invalidate_range() > mlx5_ib_update_xlt() >__get_free_pages(gfp, get_order(size)); > > However, I think this could be changed to fall back to some small > buffer if allocation fails. The existing scheme looks sketchy > > nouveau does: > > nouveau_svmm_invalidate > nvif_object_mthd >kmalloc(GFP_KERNEL) > > But I think it reliably uses a stack buffer here > > i915 I think Daniel said he audited. > > amd_mn.. The actual invalidate_range_start does not allocate memory, > but it is entangled with so many locks it would need careful analysis > to be sure. > > The others look generally OK, which is good, better than I hoped :) It is on my TODO list to get rid of allocation in notifier callback (iirc nouveau already use the stack unless it was lost in all the revision it wants through). Anyway i do not think we need allocation in notifier. Cheers, Jérôme ___ 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/buddy: tidy up i915_buddy_fini
== Series Details ==
Series: series starting with [1/2] drm/i915/buddy: tidy up i915_buddy_fini
URL : https://patchwork.freedesktop.org/series/65303/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6718 -> Patchwork_14053
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14053/
Known issues
Here are the changes found in Patchwork_14053 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14053/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@vgem_basic@dmabuf-fence-before:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-icl-u3/igt@vgem_ba...@dmabuf-fence-before.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14053/fi-icl-u3/igt@vgem_ba...@dmabuf-fence-before.html
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][5] ([fdo#08]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14053/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
Participating hosts (54 -> 45)
--
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-skl-lmem fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6718 -> Patchwork_14053
CI-20190529: 20190529
CI_DRM_6718: b6d542cb2fbbc69487b1e83634395439a8fafa94 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14053: d9255a2dc35668a15d2fe026180af2f8e35d994f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d9255a2dc356 drm/i915/buddy: use kmemleak_update_trace
5e0aab1e8c03 drm/i915/buddy: tidy up i915_buddy_fini
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14053/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "nvme-pci: use host managed power state for suspend"
On Fri, Aug 16, 2019 at 07:12:11AM -0700, Chris Wilson wrote: > Quoting Keith Busch (2019-08-16 13:46:41) > > Could you please try Rafael's solution? These two commits here: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=xps13-9380-20190812=accd2dd72c8f087441d725dd916688171519e4e6 > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=xps13-9380-20190812=4eaefe8c621c6195c91044396ed8060c179f7aae > > Which indeed work, thank you. Great! A pull request inlcuding these fixes was sent to Linus earlier today. We should expect to see its inclusion in the next -rc. ___ 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/dp/dsc: Add Support for all BPCs supported by TGL (rev4)
== Series Details == Series: drm/dp/dsc: Add Support for all BPCs supported by TGL (rev4) URL : https://patchwork.freedesktop.org/series/63526/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6713_full -> Patchwork_14038_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14038_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14038_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_14038_full: ### IGT changes ### Possible regressions * igt@gem_exec_create@forked: - shard-glk: [PASS][1] -> [TIMEOUT][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-glk7/igt@gem_exec_cre...@forked.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/shard-glk7/igt@gem_exec_cre...@forked.html Known issues Here are the changes found in Patchwork_14038_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-apl7/igt@gem_ctx_isolat...@rcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/shard-apl1/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_schedule@independent-render: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-iclb6/igt@gem_exec_sched...@independent-render.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/shard-iclb7/igt@gem_exec_sched...@independent-render.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +7 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-iclb8/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-contexts-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-iclb4/igt@gem_exec_sched...@preempt-queue-contexts-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/shard-iclb7/igt@gem_exec_sched...@preempt-queue-contexts-bsd1.html * igt@kms_color@pipe-a-ctm-blue-to-red: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([fdo#103558] / [fdo#105602]) +9 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-kbl2/igt@kms_co...@pipe-a-ctm-blue-to-red.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/shard-kbl1/igt@kms_co...@pipe-a-ctm-blue-to-red.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][13] -> [FAIL][14] ([fdo#105767]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-glk4/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/shard-glk9/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-skl8/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14038/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403]) [21]:
Re: [Intel-gfx] [PATCH] Revert "nvme-pci: use host managed power state for suspend"
Quoting Keith Busch (2019-08-16 13:46:41) > On Fri, Aug 16, 2019 at 6:38 AM Christoph Hellwig wrote: > > On Fri, Aug 16, 2019 at 01:30:29PM +0100, Chris Wilson wrote: > > > Quoting Christoph Hellwig (2019-08-16 13:26:44) > > > > Please, report the actual problem. Blindly reverting a patch without > > > > even an explanation of your regressions is not the way to do it. > > > > > > As stated, the system doesn't suspend. > > > > > > If you would like to wait, you will get test results from our CI > > > giving the current failed state and the outcome of the patch. > > > > Platform type, SSD vendor and type, firmware version? Which platform were you interested in, and is that information not present in the debug log? The issue is observed across multiple different SSD and vendors. > Also not a fan of knee-jerk reverts. Even if it may turn out to be > necessary, let's at least start with a bug report for an opportunity > to fix first! I just did report that we successfully bisected the earlier bug we reported, and was testing a revert for our CI. > Could you please try Rafael's solution? These two commits here: > > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=xps13-9380-20190812=accd2dd72c8f087441d725dd916688171519e4e6 > https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=xps13-9380-20190812=4eaefe8c621c6195c91044396ed8060c179f7aae Which indeed work, thank you. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri, Aug 16, 2019 at 2:12 PM Jason Gunthorpe wrote: > > On Fri, Aug 16, 2019 at 08:20:55AM +0200, Daniel Vetter wrote: > > On Fri, Aug 16, 2019 at 3:00 AM Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 10:49:31PM +0200, Daniel Vetter wrote: > > > > On Thu, Aug 15, 2019 at 10:27 PM Jason Gunthorpe wrote: > > > > > On Thu, Aug 15, 2019 at 10:16:43PM +0200, Daniel Vetter wrote: > > > > > > So if someone can explain to me how that works with lockdep I can of > > > > > > course implement it. But afaics that doesn't exist (I tried to > > > > > > explain > > > > > > that somewhere else already), and I'm no really looking forward to > > > > > > hacking also on lockdep for this little series. > > > > > > > > > > Hmm, kind of looks like it is done by calling preempt_disable() > > > > > > > > Yup. That was v1, then came the suggestion that disabling preemption > > > > is maybe not the best thing (the oom reaper could still run for a long > > > > time comparatively, if it's cleaning out gigabytes of process memory > > > > or what not, hence this dedicated debug infrastructure). > > > > > > Oh, I'm coming in late, sorry > > > > > > Anyhow, I was thinking since we agreed this can trigger on some > > > CONFIG_DEBUG flag, something like > > > > > > /* This is a sleepable region, but use preempt_disable to get > > > debugging > > > * for calls that are not allowed to block for OOM [.. insert > > > * Michal's explanation.. ] */ > > > if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && > > > !mmu_notifier_range_blockable(range)) > > > preempt_disable(); > > > ops->invalidate_range_start(); > > > > I think we also discussed that, and some expressed concerns it would > > change behaviour/timing too much for testing. Since this does does > > disable preemption for real, not just for might_sleep. > > I don't follow, this is a debug kernel, it will have widly different > timing. > > Further the point of this debugging on atomic_sleep is to be as > timing-independent as possible since functions with rare sleeps should > be guarded by might_sleep() in their common paths. > > I guess I don't get the push to have some low overhead debugging for > this? Is there something special you are looking for? Don't ask me, I'm just trying to get _some_ debugging for this in. I don't care one bit how much overhead it has because in our CI our debug build has lockdep and everything and it crawls anyway. I started out with the preempt_disable/enable thing like you suggested, and a few rounds later we're here. We can go back to v1 on this one, but I'd prefer to not do the lap too often. Also, aside from this patch (which is prep for the next) and some simple reordering conflicts they're all independent. So if there's no way to paint this bikeshed here (technicolor perhaps?) then I'd like to get at least the others considered. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux Kernel 5.2.8 (uvc or i915?)
On Thu, 15 Aug 2019, Randy Dunlap wrote: > On 8/15/19 6:15 PM, Nathaniel Russell wrote: >> I would really like help with the kernel error with my uvcvideo driver. >> > > Hi again. > > What makes you think that the problem is related to the uvcvideo driver? > Does some previous kernel version work correctly? If so, what version(s)? > > > Does this warning message only happen when the uvcvideo driver is being > loaded? > Can you suppress loading of the uvcvideo driver to find out? > > Most of the problems/errors/warnings that I see are related to the i915 > driver: > > [ 13.032341] timed out waiting for port C ready: got 0x20, expected 0xe0 > [ 13.032872] WARNING: CPU: 1 PID: 239 at > drivers/gpu/drm/i915/intel_display.c:1597 vlv_wait_port_ready+0x99/0xe0 [i915] > [ 13.033632] RIP: 0010:vlv_wait_port_ready+0x99/0xe0 [i915] > > although there are a few uvcvideo warnings: > [ 13.039305] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not > initialized! > [ 13.039318] uvcvideo 1-5:1.0: Entity type for entity Extension 3 was not > initialized! > [ 13.039330] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not > initialized! > [ 13.039339] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not > initialized! > > > Laurent, do you see any uvc issues here? Any ideas/suggestions? > > > @intel-gfx: any ideas about what is going on here with the i915 driver? Please file a bug over at [1], add drm.debug=14 module parameter, attach dmesg to the bug, all the way from boot to reproducing the issue. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel > > > > Original message to lkml: > https://lore.kernel.org/lkml/CAONH+Jm-O6=dq+k2n5pntnmg2sq1kcvnfluwevh6w82opef...@mail.gmail.com/T/#u > > Previous message for 5.1.21 kernel: > https://lore.kernel.org/lkml/CAONH+JkTFujY9vEyNNuem+9rJ2qBKkf-PbKk9=DBSVEp6kW=y...@mail.gmail.com/ > > > thanks. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/4] drm/i915/gt: Track timeline activeness in enter/exit
== Series Details == Series: series starting with [CI,1/4] drm/i915/gt: Track timeline activeness in enter/exit URL : https://patchwork.freedesktop.org/series/65274/ State : success == Summary == CI Bug Log - changes from CI_DRM_6713_full -> Patchwork_14037_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14037_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preempt-queue-bsd2: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +7 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-iclb2/igt@gem_exec_sched...@preempt-queue-bsd2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/shard-iclb7/igt@gem_exec_sched...@preempt-queue-bsd2.html * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#104108]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-skl3/igt@gem_soft...@noreloc-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/shard-skl7/igt@gem_soft...@noreloc-s3.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108] / [fdo#107807]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-skl4/igt@i915_pm_...@system-suspend-execbuf.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/shard-skl3/igt@i915_pm_...@system-suspend-execbuf.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][7] -> [FAIL][8] ([fdo#105767]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_cursor_legacy@pipe-a-torture-move: - shard-kbl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103665]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-kbl6/igt@kms_cursor_leg...@pipe-a-torture-move.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/shard-kbl2/igt@kms_cursor_leg...@pipe-a-torture-move.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#105363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-skl3/igt@kms_f...@flip-vs-expired-vblank.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/shard-skl6/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-pgflip-blt: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-pgflip-blt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-pgflip-blt.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-skl8/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/shard-skl5/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [fdo#110403]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html Possible fixes * igt@gem_exec_schedule@pi-ringfull-bsd: - shard-iclb: [SKIP][21] ([fdo#111325]) -> [PASS][22] +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-iclb4/igt@gem_exec_sched...@pi-ringfull-bsd.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14037/shard-iclb7/igt@gem_exec_sched...@pi-ringfull-bsd.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [SKIP][23] ([fdo#109271]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6713/shard-snb1/igt@i915_pm_rc6_reside...@rc6-accuracy.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only emit the 'send bug report' once for a GPU hang
== Series Details ==
Series: drm/i915: Only emit the 'send bug report' once for a GPU hang
URL : https://patchwork.freedesktop.org/series/65301/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6718 -> Patchwork_14052
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/
Known issues
Here are the changes found in Patchwork_14052 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@gem_flink_basic@flink-lifetime:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
Participating hosts (54 -> 44)
--
Missing(10): fi-kbl-soraka fi-ilk-m540 fi-skl-gvtdvm fi-hsw-4200u
fi-byt-squawks fi-bsw-cyan fi-apl-guc fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6718 -> Patchwork_14052
CI-20190529: 20190529
CI_DRM_6718: b6d542cb2fbbc69487b1e83634395439a8fafa94 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14052: d972e9390d69c1d6e2ef798a365640a0cf4a63a5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d972e9390d69 drm/i915: Only emit the 'send bug report' once for a GPU hang
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14052/
___
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: Sanitize PHY state during display core uninit
== Series Details ==
Series: drm/i915: Sanitize PHY state during display core uninit
URL : https://patchwork.freedesktop.org/series/65298/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6718 -> Patchwork_14050
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/
Known issues
Here are the changes found in Patchwork_14050 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][3] ([fdo#08]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (54 -> 45)
--
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-skl-guc
fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6718 -> Patchwork_14050
CI-20190529: 20190529
CI_DRM_6718: b6d542cb2fbbc69487b1e83634395439a8fafa94 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14050: edfd85985b68f1974f531b0a154461c1b62fe561 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
edfd85985b68 drm/i915: Sanitize PHY state during display core uninit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14050/
___
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/buddy: tidy up i915_buddy_fini (rev2)
== Series Details == Series: drm/i915/buddy: tidy up i915_buddy_fini (rev2) URL : https://patchwork.freedesktop.org/series/65299/ State : failure == Summary == Applying: drm/i915/buddy: tidy up i915_buddy_fini error: corrupt patch at line 20 error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915/buddy: tidy up i915_buddy_fini When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "nvme-pci: use host managed power state for suspend"
On Fri, Aug 16, 2019 at 01:30:29PM +0100, Chris Wilson wrote: > Quoting Christoph Hellwig (2019-08-16 13:26:44) > > Please, report the actual problem. Blindly reverting a patch without > > even an explanation of your regressions is not the way to do it. > > As stated, the system doesn't suspend. > > If you would like to wait, you will get test results from our CI > giving the current failed state and the outcome of the patch. Platform type, SSD vendor and type, firmware version? ___ 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/gtt: Fold gen8 insertions into one (rev2)
== Series Details ==
Series: drm/i915/gtt: Fold gen8 insertions into one (rev2)
URL : https://patchwork.freedesktop.org/series/65258/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6718 -> Patchwork_14049
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/
Known issues
Here are the changes found in Patchwork_14049 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@gem_flink_basic@flink-lifetime:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +2
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/fi-icl-u3/igt@gem_flink_ba...@flink-lifetime.html
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][5] ([fdo#08]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [FAIL][7] ([fdo#103167]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6718/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#44]: https://bugs.freedesktop.org/show_bug.cgi?id=44
Participating hosts (54 -> 46)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6718 -> Patchwork_14049
CI-20190529: 20190529
CI_DRM_6718: b6d542cb2fbbc69487b1e83634395439a8fafa94 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14049: b3be26f7222586648678d45c884961b4f7a135fc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b3be26f72225 drm/i915/gtt: Fold gen8 insertions into one
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14049/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "nvme-pci: use host managed power state for suspend"
Quoting Christoph Hellwig (2019-08-16 13:26:44) > Please, report the actual problem. Blindly reverting a patch without > even an explanation of your regressions is not the way to do it. As stated, the system doesn't suspend. If you would like to wait, you will get test results from our CI giving the current failed state and the outcome of the patch. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Fri 16-08-19 09:19:06, Jason Gunthorpe wrote: > On Fri, Aug 16, 2019 at 10:10:29AM +0200, Michal Hocko wrote: > > On Thu 15-08-19 17:13:23, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 09:35:26PM +0200, Michal Hocko wrote: > > > > > > > > The last detail is I'm still unclear what a GFP flags a blockable > > > > > invalidate_range_start() should use. Is GFP_KERNEL OK? > > > > > > > > I hope I will not make this muddy again ;) > > > > invalidate_range_start in the blockable mode can use/depend on any > > > > sleepable > > > > allocation allowed in the context it is called from. > > > > > > 'in the context is is called from' is the magic phrase, as > > > invalidate_range_start is called while holding several different mm > > > related locks. I know at least write mmap_sem and i_mmap_rwsem > > > (write?) > > > > > > Can GFP_KERNEL be called while holding those locks? > > > > i_mmap_rwsem would be problematic because it is taken during the > > reclaim. > > Okay.. So the fs_reclaim debugging does catch errors. I do not think fs_reclaim is the udnerlying mechanism to catch this deadlock. It is a simple AA deadlock. You take i_mmap_rwsem and then go down the allocation path, direct reclaim and take the lock again. Nothing really surprising. fs_reclaim is really to catch GFP_NOFS context calling into a less restricted (e.g. GFP_KERNEL allocation context). > Do you have any > reference for what a false positive looks like? I believe I have given some examples when introducing __GFP_NOLOCKDEP. > I would like to inject it into the notifier path as this is very > difficult for driver authors to discover and know about, but I'm > worried about your false positive remark. > > I think I understand we can use only GFP_ATOMIC in the notifiers, but > we need a strategy to handle OOM to guarentee forward progress. Your example is from the notifier registration IIUC. Can you pre-allocate before taking locks? Could you point me to some examples when the allocation is necessary in the range notifier callback? -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "nvme-pci: use host managed power state for suspend"
Please, report the actual problem. Blindly reverting a patch without even an explanation of your regressions is not the way to do it. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree
On Fri, Aug 16, 2019 at 12:47:15PM +0300, Laurent Pinchart wrote:
> On Fri, Aug 16, 2019 at 08:23:54AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 16, 2019 at 6:48 AM Sam Ravnborg wrote:
> > > > Hi all,
> > > >
> > > > After merging the drm-misc tree, today's linux-next build (x86_64
> > > > allmodconfig) produced this warning:
> > > >
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.ko
> > > > drivers/gpu/drm/panel/panel-nec-nl8048hl11.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.ko
> > > > drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.ko
> > > > drivers/gpu/drm/panel/panel-sony-acx565akm.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.ko
> > > > drivers/gpu/drm/panel/panel-tpo-td028ttec1.ko
> > > > warning: same module names found:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.ko
> > > > drivers/gpu/drm/panel/panel-tpo-td043mtea1.ko
> > > >
> > > > Introduced by commits
> > > >
> > > > df439abe6501 ("drm/panel: Add driver for the NEC NL8048HL11 panel")
> > > > c9cf4c2a3bd3 ("drm/panel: Add driver for the Sharp LS037V7DW01 panel")
> > > > 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
> > > > 415b8dd08711 ("drm/panel: Add driver for the Toppoly TD028TTEC1
> > > > panel")
> > > > dc2e1e5b2799 ("drm/panel: Add driver for the Toppoly TD043MTEA1
> > > > panel")
> > >
> > > Ups, had not seen this one coming.
> > > We are in the process of removing the drivers in
> > > drivers/video/fbdev/omap2/omapfb/
> > > and decided to introduce the new drivers early to get them out of a
> > > longer patch series.
>
> Oops :-(
>
> The new drivers were initially part of a patch series that removed the
> duplicated drivers. The new drivers then got fast-tracked, and I didn't
> notice this issue.
>
> > Should we have a config dependency to not allow the old fbdev omap
> > when the drm omap driver is enabled? I think that would take care of
> > all this.
> >
> > Or too annoying for development?
> >
> > Also note that fbdev is in drm-misc now, so we should be able to fix
> > this all without cross-tree conflicts.
>
> Note that drivers/video/fbdev/omap2/omapfb/ will stay, it's
> drivers/gpu/drm/omapdrm/displays/ that is being removed. FB_OMAP2
> already depends on DRM_OMAP = n, I propose doing something similar at
> the level of the individual display drivers.
I've just posted "[PATCH 0/2] Fix module name clash with omapdrm and DRM
panel modules" that should solve this issue.
--
Regards,
Laurent Pinchart
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "nvme-pci: use host managed power state for suspend"
commit d916b1be94b6dc8d293abed2451f3062f6af7551
Author: Keith Busch
Date: Thu May 23 09:27:35 2019 -0600
nvme-pci: use host managed power state for suspend
Bisected as cause of suspend failure for gem_eio/suspend on multiple kbl
hosts.
Cc: Rafael J. Wysocki
Cc: Keith Busch
Cc: Sagi Grimberg
Cc: Christoph Hellwig
Cc: Keith Busch
Cc: Jens Axboe
Cc: linux-n...@lists.infradead.org
---
drivers/nvme/host/pci.c | 95 ++---
1 file changed, 3 insertions(+), 92 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index db160cee42ad..bdc9e0625bb7 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -111,7 +110,6 @@ struct nvme_dev {
u32 cmbsz;
u32 cmbloc;
struct nvme_ctrl ctrl;
- u32 last_ps;
mempool_t *iod_mempool;
@@ -2831,94 +2829,16 @@ static void nvme_remove(struct pci_dev *pdev)
}
#ifdef CONFIG_PM_SLEEP
-static int nvme_get_power_state(struct nvme_ctrl *ctrl, u32 *ps)
-{
- return nvme_get_features(ctrl, NVME_FEAT_POWER_MGMT, 0, NULL, 0, ps);
-}
-
-static int nvme_set_power_state(struct nvme_ctrl *ctrl, u32 ps)
-{
- return nvme_set_features(ctrl, NVME_FEAT_POWER_MGMT, ps, NULL, 0, NULL);
-}
-
-static int nvme_resume(struct device *dev)
-{
- struct nvme_dev *ndev = pci_get_drvdata(to_pci_dev(dev));
- struct nvme_ctrl *ctrl = >ctrl;
-
- if (pm_resume_via_firmware() || !ctrl->npss ||
- nvme_set_power_state(ctrl, ndev->last_ps) != 0)
- nvme_reset_ctrl(ctrl);
- return 0;
-}
-
static int nvme_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct nvme_dev *ndev = pci_get_drvdata(pdev);
- struct nvme_ctrl *ctrl = >ctrl;
- int ret = -EBUSY;
-
- /*
-* The platform does not remove power for a kernel managed suspend so
-* use host managed nvme power settings for lowest idle power if
-* possible. This should have quicker resume latency than a full device
-* shutdown. But if the firmware is involved after the suspend or the
-* device does not support any non-default power states, shut down the
-* device fully.
-*/
- if (pm_suspend_via_firmware() || !ctrl->npss) {
- nvme_dev_disable(ndev, true);
- return 0;
- }
-
- nvme_start_freeze(ctrl);
- nvme_wait_freeze(ctrl);
- nvme_sync_queues(ctrl);
-
- if (ctrl->state != NVME_CTRL_LIVE &&
- ctrl->state != NVME_CTRL_ADMIN_ONLY)
- goto unfreeze;
-
- ndev->last_ps = 0;
- ret = nvme_get_power_state(ctrl, >last_ps);
- if (ret < 0)
- goto unfreeze;
-
- ret = nvme_set_power_state(ctrl, ctrl->npss);
- if (ret < 0)
- goto unfreeze;
-
- if (ret) {
- /*
-* Clearing npss forces a controller reset on resume. The
-* correct value will be resdicovered then.
-*/
- nvme_dev_disable(ndev, true);
- ctrl->npss = 0;
- ret = 0;
- goto unfreeze;
- }
- /*
-* A saved state prevents pci pm from generically controlling the
-* device's power. If we're using protocol specific settings, we don't
-* want pci interfering.
-*/
- pci_save_state(pdev);
-unfreeze:
- nvme_unfreeze(ctrl);
- return ret;
-}
-
-static int nvme_simple_suspend(struct device *dev)
-{
- struct nvme_dev *ndev = pci_get_drvdata(to_pci_dev(dev));
nvme_dev_disable(ndev, true);
return 0;
}
-static int nvme_simple_resume(struct device *dev)
+static int nvme_resume(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct nvme_dev *ndev = pci_get_drvdata(pdev);
@@ -2926,16 +2846,9 @@ static int nvme_simple_resume(struct device *dev)
nvme_reset_ctrl(>ctrl);
return 0;
}
+#endif
-static const struct dev_pm_ops nvme_dev_pm_ops = {
- .suspend= nvme_suspend,
- .resume = nvme_resume,
- .freeze = nvme_simple_suspend,
- .thaw = nvme_simple_resume,
- .poweroff = nvme_simple_suspend,
- .restore= nvme_simple_resume,
-};
-#endif /* CONFIG_PM_SLEEP */
+static SIMPLE_DEV_PM_OPS(nvme_dev_pm_ops, nvme_suspend, nvme_resume);
static pci_ers_result_t nvme_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
@@ -3042,11 +2955,9 @@ static struct pci_driver nvme_driver = {
.probe = nvme_probe,
.remove = nvme_remove,
.shutdown = nvme_shutdown,
-#ifdef CONFIG_PM_SLEEP
.driver = {
.pm = _dev_pm_ops,
},
-#endif
.sriov_configure =
[Intel-gfx] [CI 2/2] drm/i915: Markup expected timeline locks for i915_active
As every i915_active_request should be serialised by a dedicated lock,
i915_active consists of a tree of locks; one for each node. Markup up
the i915_active_request with what lock is supposed to be guarding it so
that we can verify that the serialised updated are indeed serialised.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context.c | 11 +++
drivers/gpu/drm/i915/gt/intel_engine_pool.h | 2 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 7 +++
drivers/gpu/drm/i915/gt/selftest_timeline.c | 4
.../gpu/drm/i915/gt/selftests/mock_timeline.c | 2 +-
drivers/gpu/drm/i915/i915_active.c| 19 +++
drivers/gpu/drm/i915/i915_active.h| 12 ++--
drivers/gpu/drm/i915/i915_active_types.h | 15 +++
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
drivers/gpu/drm/i915/selftests/i915_active.c | 3 +--
13 files changed, 58 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index e1248eace0e1..eca41c4a5aa6 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -230,7 +230,7 @@ alloc_request(struct intel_overlay *overlay, void
(*fn)(struct intel_overlay *))
if (IS_ERR(rq))
return rq;
- err = i915_active_ref(>last_flip, rq->fence.context, rq);
+ err = i915_active_ref(>last_flip, rq->timeline, rq);
if (err) {
i915_request_add(rq);
return ERR_PTR(err);
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 6a4e84157bf2..818ac6915bc5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -211,7 +211,7 @@ static void clear_pages_worker(struct work_struct *work)
* keep track of the GPU activity within this vma/request, and
* propagate the signal from the request to w->dma.
*/
- err = i915_active_ref(>active, rq->fence.context, rq);
+ err = i915_active_ref(>active, rq->timeline, rq);
if (err)
goto out_request;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index a6b0cb714292..cd1fd2e5423a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -908,7 +908,7 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
if (emit)
err = emit(rq, data);
if (err == 0)
- err = i915_active_ref(>base, rq->fence.context, rq);
+ err = i915_active_ref(>base, rq->timeline, rq);
i915_request_add(rq);
if (err)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 9114953bf920..f55691d151ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -306,10 +306,10 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
/* Queue this switch after current activity by this context. */
err = i915_active_request_set(>last_request, rq);
+ mutex_unlock(>mutex);
if (err)
- goto unlock;
+ return err;
}
- lockdep_assert_held(>mutex);
/*
* Guarantee context image and the timeline remains pinned until the
@@ -319,12 +319,7 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
* words transfer the pinned ce object to tracked active request.
*/
GEM_BUG_ON(i915_active_is_idle(>active));
- err = i915_active_ref(>active, rq->fence.context, rq);
-
-unlock:
- if (rq->timeline != tl)
- mutex_unlock(>mutex);
- return err;
+ return i915_active_ref(>active, rq->timeline, rq);
}
struct i915_request *intel_context_create_request(struct intel_context *ce)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pool.h
b/drivers/gpu/drm/i915/gt/intel_engine_pool.h
index f7a0a660c1c9..8d069efd9457 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pool.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pool.h
@@ -18,7 +18,7 @@ static inline int
intel_engine_pool_mark_active(struct intel_engine_pool_node *node,
struct i915_request *rq)
{
- return i915_active_ref(>active, rq->fence.context, rq);
+ return i915_active_ref(>active, rq->timeline, rq);
}
static inline void
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
[Intel-gfx] [CI 1/2] drm/i915/gt: Mark context->active_count as protected by timeline->mutex
We use timeline->mutex to protect modifications to
context->active_count, and the associated enable/disable callbacks.
Due to complications with engine-pm barrier there is a path where we used
a "superlock" to provide serialised protect and so could not
unconditionally assert with lockdep that it was always held. However,
we can mark the mutex as taken (noting that we may be nested underneath
ourselves) which means we can be reassured the right timeline->mutex is
always treated as held and let lockdep roam free.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_context.h | 3 +++
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 14 ++
drivers/gpu/drm/i915/gt/intel_timeline.c | 4
drivers/gpu/drm/i915/i915_request.c | 3 ++-
5 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 053a1307ecb4..dd742ac2fbdb 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -89,17 +89,20 @@ void intel_context_exit_engine(struct intel_context *ce);
static inline void intel_context_enter(struct intel_context *ce)
{
+ lockdep_assert_held(>timeline->mutex);
if (!ce->active_count++)
ce->ops->enter(ce);
}
static inline void intel_context_mark_active(struct intel_context *ce)
{
+ lockdep_assert_held(>timeline->mutex);
++ce->active_count;
}
static inline void intel_context_exit(struct intel_context *ce)
{
+ lockdep_assert_held(>timeline->mutex);
GEM_BUG_ON(!ce->active_count);
if (!--ce->active_count)
ce->ops->exit(ce);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index a632b20ec4d8..616f3f9a6825 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -61,7 +61,7 @@ struct intel_context {
u32 *lrc_reg_state;
u64 lrc_desc;
- unsigned int active_count; /* notionally protected by timeline->mutex */
+ unsigned int active_count; /* protected by timeline->mutex */
atomic_t pin_count;
struct mutex pin_mutex; /* guards pinning and associated on-gpuing */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index f3f0109f9e22..5f03f7dcad72 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -37,6 +37,16 @@ static int __engine_unpark(struct intel_wakeref *wf)
return 0;
}
+static inline void __timeline_mark_lock(struct intel_context *ce)
+{
+ mutex_acquire(>timeline->mutex.dep_map, 2, 0, _THIS_IP_);
+}
+
+static inline void __timeline_mark_unlock(struct intel_context *ce)
+{
+ mutex_release(>timeline->mutex.dep_map, 0, _THIS_IP_);
+}
+
static bool switch_to_kernel_context(struct intel_engine_cs *engine)
{
struct i915_request *rq;
@@ -61,6 +71,8 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
* retiring the last request, thus all rings should be empty and
* all timelines idle.
*/
+ __timeline_mark_lock(engine->kernel_context);
+
rq = __i915_request_create(engine->kernel_context, GFP_NOWAIT);
if (IS_ERR(rq))
/* Context switch failed, hope for the best! Maybe reset? */
@@ -80,6 +92,8 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
__intel_wakeref_defer_park(>wakeref);
__i915_request_queue(rq, NULL);
+ __timeline_mark_unlock(engine->kernel_context);
+
return false;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 7b476cd55dac..eafd94d5e211 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -338,6 +338,8 @@ void intel_timeline_enter(struct intel_timeline *tl)
{
struct intel_gt_timelines *timelines = >gt->timelines;
+ lockdep_assert_held(>mutex);
+
GEM_BUG_ON(!atomic_read(>pin_count));
if (tl->active_count++)
return;
@@ -352,6 +354,8 @@ void intel_timeline_exit(struct intel_timeline *tl)
{
struct intel_gt_timelines *timelines = >gt->timelines;
+ lockdep_assert_held(>mutex);
+
GEM_BUG_ON(!tl->active_count);
if (--tl->active_count)
return;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 174c7fdd02ff..7edcd0fef5c6 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1087,7 +1087,8 @@ __i915_request_add_to_timeline(struct i915_request *rq)
* precludes optimising to use semaphores serialisation of a single
*
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Markup expected timeline locks for i915_active
Quoting Mika Kuoppala (2019-08-16 13:02:21)
> > diff --git a/drivers/gpu/drm/i915/i915_active_types.h
> > b/drivers/gpu/drm/i915/i915_active_types.h
> > index ae3ee441c114..d857bd12aa7e 100644
> > --- a/drivers/gpu/drm/i915/i915_active_types.h
> > +++ b/drivers/gpu/drm/i915/i915_active_types.h
> > @@ -24,6 +24,9 @@ struct i915_active_request {
> > struct i915_request __rcu *request;
> > struct list_head link;
> > i915_active_retire_fn retire;
> > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
> > + struct mutex *lock;
>
> Checkpatch thinks the usage should be somehow stated with comment.
>
> So put something like
> /* Incorporeal. Ref piggypacking timeline for lockdep */
I'm using incorporeal. :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Markup expected timeline locks for i915_active
Chris Wilson writes:
> As every i915_active_request should be serialised by a dedicated lock,
> i915_active consists of a tree of locks; one for each node. Markup up
> the i915_active_request with what lock is supposed to be guarding it so
> that we can verify that the serialised updated are indeed serialised.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
> .../gpu/drm/i915/gem/i915_gem_client_blt.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_context.c | 11 +++
> drivers/gpu/drm/i915/gt/intel_engine_pool.h | 2 +-
> drivers/gpu/drm/i915/gt/intel_timeline.c | 7 +++
> drivers/gpu/drm/i915/gt/selftest_timeline.c | 4
> .../gpu/drm/i915/gt/selftests/mock_timeline.c | 2 +-
> drivers/gpu/drm/i915/i915_active.c| 19 +++
> drivers/gpu/drm/i915/i915_active.h| 12 ++--
> drivers/gpu/drm/i915/i915_active_types.h | 3 +++
> drivers/gpu/drm/i915/i915_vma.c | 4 ++--
> drivers/gpu/drm/i915/selftests/i915_active.c | 3 +--
> 13 files changed, 46 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
> b/drivers/gpu/drm/i915/display/intel_overlay.c
> index e1248eace0e1..eca41c4a5aa6 100644
> --- a/drivers/gpu/drm/i915/display/intel_overlay.c
> +++ b/drivers/gpu/drm/i915/display/intel_overlay.c
> @@ -230,7 +230,7 @@ alloc_request(struct intel_overlay *overlay, void
> (*fn)(struct intel_overlay *))
> if (IS_ERR(rq))
> return rq;
>
> - err = i915_active_ref(>last_flip, rq->fence.context, rq);
> + err = i915_active_ref(>last_flip, rq->timeline, rq);
> if (err) {
> i915_request_add(rq);
> return ERR_PTR(err);
> 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 6a4e84157bf2..818ac6915bc5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> @@ -211,7 +211,7 @@ static void clear_pages_worker(struct work_struct *work)
>* keep track of the GPU activity within this vma/request, and
>* propagate the signal from the request to w->dma.
>*/
> - err = i915_active_ref(>active, rq->fence.context, rq);
> + err = i915_active_ref(>active, rq->timeline, rq);
> if (err)
> goto out_request;
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index a6b0cb714292..cd1fd2e5423a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -908,7 +908,7 @@ static int context_barrier_task(struct i915_gem_context
> *ctx,
> if (emit)
> err = emit(rq, data);
> if (err == 0)
> - err = i915_active_ref(>base, rq->fence.context, rq);
> + err = i915_active_ref(>base, rq->timeline, rq);
>
> i915_request_add(rq);
> if (err)
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index 9114953bf920..f55691d151ae 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -306,10 +306,10 @@ int intel_context_prepare_remote_request(struct
> intel_context *ce,
>
> /* Queue this switch after current activity by this context. */
> err = i915_active_request_set(>last_request, rq);
> + mutex_unlock(>mutex);
> if (err)
> - goto unlock;
> + return err;
> }
> - lockdep_assert_held(>mutex);
>
> /*
>* Guarantee context image and the timeline remains pinned until the
> @@ -319,12 +319,7 @@ int intel_context_prepare_remote_request(struct
> intel_context *ce,
>* words transfer the pinned ce object to tracked active request.
>*/
> GEM_BUG_ON(i915_active_is_idle(>active));
> - err = i915_active_ref(>active, rq->fence.context, rq);
> -
> -unlock:
> - if (rq->timeline != tl)
> - mutex_unlock(>mutex);
> - return err;
> + return i915_active_ref(>active, rq->timeline, rq);
There seem to have been so much work here for no apparent gains.
Good riddance.
> }
>
> struct i915_request *intel_context_create_request(struct intel_context *ce)
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pool.h
> b/drivers/gpu/drm/i915/gt/intel_engine_pool.h
> index f7a0a660c1c9..8d069efd9457 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pool.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pool.h
> @@ -18,7 +18,7 @@ static inline int
> intel_engine_pool_mark_active(struct intel_engine_pool_node *node,
> struct i915_request *rq)
> {
> - return
[Intel-gfx] [PATCH] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock
If we only call process_csb() from the tasklet, though we lose the
ability to bypass ksoftirqd interrupt processing on direct submission
paths, we can push it out of the irq-off spinlock.
The penalty is that we then allow schedule_out to be called concurrently
with schedule_in requiring us to handle the usage count (baked into the
pointer itself) atomically.
As we do kick the tasklets (via local_bh_enable()) after our submission,
there is a possibility there to see if we can pull the local softirq
processing back from the ksoftirqd.
v2: Store the 'switch_priority_hint' on submission, so that we can
safely check during process_csb().
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 136 +++---
drivers/gpu/drm/i915/i915_utils.h | 20 ++-
5 files changed, 108 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index a632b20ec4d8..d8ce266c049f 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -41,9 +41,7 @@ struct intel_context {
struct intel_engine_cs *engine;
struct intel_engine_cs *inflight;
#define intel_context_inflight(ce) ptr_mask_bits((ce)->inflight, 2)
-#define intel_context_inflight_count(ce) ptr_unmask_bits((ce)->inflight, 2)
-#define intel_context_inflight_inc(ce) ptr_count_inc(&(ce)->inflight)
-#define intel_context_inflight_dec(ce) ptr_count_dec(&(ce)->inflight)
+#define intel_context_inflight_count(ce) ptr_unmask_bits((ce)->inflight, 2)
struct i915_address_space *vm;
struct i915_gem_context *gem_context;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 957f27a2ec97..ba457c1c7dc0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1459,7 +1459,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
*engine)
for (port = execlists->pending; (rq = *port); port++) {
/* Exclude any contexts already counted in active */
- if (intel_context_inflight_count(rq->hw_context) == 1)
+ if (!intel_context_inflight_count(rq->hw_context))
engine->stats.active++;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 9965a32601d6..5441aa9cb863 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -204,6 +204,16 @@ struct intel_engine_execlists {
*/
unsigned int port_mask;
+ /**
+* @switch_priority_hint: Second context priority.
+*
+* We submit multiple contexts to the HW simultaneously and would
+* like to occasionally switch between them to emulate timeslicing.
+* To know when timeslicing is suitable, we track the priority of
+* the context submitted second.
+*/
+ int switch_priority_hint;
+
/**
* @queue_priority_hint: Highest pending priority.
*
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e9863f4d826b..2978cf16fb9b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -547,27 +547,39 @@ execlists_context_status_change(struct i915_request *rq,
unsigned long status)
status, rq);
}
+static inline struct intel_engine_cs *
+__execlists_schedule_in(struct i915_request *rq)
+{
+ struct intel_engine_cs * const engine = rq->engine;
+ struct intel_context * const ce = rq->hw_context;
+
+ intel_context_get(ce);
+
+ intel_gt_pm_get(engine->gt);
+ execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
+ intel_engine_context_in(engine);
+
+ return engine;
+}
+
static inline struct i915_request *
execlists_schedule_in(struct i915_request *rq, int idx)
{
- struct intel_context *ce = rq->hw_context;
- int count;
+ struct intel_context * const ce = rq->hw_context;
+ struct intel_engine_cs *old;
+ GEM_BUG_ON(!intel_engine_pm_is_awake(rq->engine));
trace_i915_request_in(rq, idx);
- count = intel_context_inflight_count(ce);
- if (!count) {
- intel_context_get(ce);
- ce->inflight = rq->engine;
-
- intel_gt_pm_get(ce->inflight->gt);
- execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
- intel_engine_context_in(ce->inflight);
- }
+ old = READ_ONCE(ce->inflight);
+ do {
+ if (!old) {
+
Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Mark context->active_count as protected by timeline->mutex
Chris Wilson writes:
> We use timeline->mutex to protect modifications to
> context->active_count, and the associated enable/disable callbacks.
> Due to complications with engine-pm barrier there is a path where we used
> a "superlock" to provide serialised protect and so could not
> unconditionally assert with lockdep that it was always held. However,
> we can mark the mutex as taken (noting that we may be nested underneath
> ourselves) which means we can be reassured the right timeline->mutex is
> always treated as held and let lockdep roam free.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_context.h | 3 +++
> drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +-
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 14 ++
> drivers/gpu/drm/i915/gt/intel_timeline.c | 4
> drivers/gpu/drm/i915/i915_request.c | 3 ++-
> 5 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> b/drivers/gpu/drm/i915/gt/intel_context.h
> index 053a1307ecb4..dd742ac2fbdb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -89,17 +89,20 @@ void intel_context_exit_engine(struct intel_context *ce);
>
> static inline void intel_context_enter(struct intel_context *ce)
> {
> + lockdep_assert_held(>timeline->mutex);
> if (!ce->active_count++)
> ce->ops->enter(ce);
> }
>
> static inline void intel_context_mark_active(struct intel_context *ce)
> {
> + lockdep_assert_held(>timeline->mutex);
> ++ce->active_count;
> }
>
> static inline void intel_context_exit(struct intel_context *ce)
> {
> + lockdep_assert_held(>timeline->mutex);
> GEM_BUG_ON(!ce->active_count);
> if (!--ce->active_count)
> ce->ops->exit(ce);
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> b/drivers/gpu/drm/i915/gt/intel_context_types.h
> index d8ce266c049f..bf9cedfccbf0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> @@ -59,7 +59,7 @@ struct intel_context {
> u32 *lrc_reg_state;
> u64 lrc_desc;
>
> - unsigned int active_count; /* notionally protected by timeline->mutex */
> + unsigned int active_count; /* protected by timeline->mutex */
>
> atomic_t pin_count;
> struct mutex pin_mutex; /* guards pinning and associated on-gpuing */
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index f3f0109f9e22..5f03f7dcad72 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -37,6 +37,16 @@ static int __engine_unpark(struct intel_wakeref *wf)
> return 0;
> }
>
> +static inline void __timeline_mark_lock(struct intel_context *ce)
> +{
> + mutex_acquire(>timeline->mutex.dep_map, 2, 0, _THIS_IP_);
> +}
> +
> +static inline void __timeline_mark_unlock(struct intel_context *ce)
> +{
> + mutex_release(>timeline->mutex.dep_map, 0, _THIS_IP_);
> +}
> +
> static bool switch_to_kernel_context(struct intel_engine_cs *engine)
> {
> struct i915_request *rq;
> @@ -61,6 +71,8 @@ static bool switch_to_kernel_context(struct intel_engine_cs
> *engine)
>* retiring the last request, thus all rings should be empty and
>* all timelines idle.
>*/
> + __timeline_mark_lock(engine->kernel_context);
> +
> rq = __i915_request_create(engine->kernel_context, GFP_NOWAIT);
> if (IS_ERR(rq))
> /* Context switch failed, hope for the best! Maybe reset? */
> @@ -80,6 +92,8 @@ static bool switch_to_kernel_context(struct intel_engine_cs
> *engine)
> __intel_wakeref_defer_park(>wakeref);
> __i915_request_queue(rq, NULL);
>
> + __timeline_mark_unlock(engine->kernel_context);
> +
> return false;
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
> b/drivers/gpu/drm/i915/gt/intel_timeline.c
> index 7b476cd55dac..eafd94d5e211 100644
> --- a/drivers/gpu/drm/i915/gt/intel_timeline.c
> +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
> @@ -338,6 +338,8 @@ void intel_timeline_enter(struct intel_timeline *tl)
> {
> struct intel_gt_timelines *timelines = >gt->timelines;
>
> + lockdep_assert_held(>mutex);
> +
> GEM_BUG_ON(!atomic_read(>pin_count));
> if (tl->active_count++)
> return;
> @@ -352,6 +354,8 @@ void intel_timeline_exit(struct intel_timeline *tl)
> {
> struct intel_gt_timelines *timelines = >gt->timelines;
>
> + lockdep_assert_held(>mutex);
> +
> GEM_BUG_ON(!tl->active_count);
> if (--tl->active_count)
> return;
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index 174c7fdd02ff..7edcd0fef5c6 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++
Re: [Intel-gfx] [PULL] drm-misc-next
Quoting Maxime Ripard (2019-08-16 12:32:01) > Hi Daniel, Dave, > > Here's this week drm-misc-next PR. > > Maxime > > drm-misc-next-2019-08-16: > drm-misc-next for 5.4: > > UAPI Changes: > > Cross-subsystem Changes: > > Core Changes: > - dma-buf: add reservation_object_fences helper, relax > reservation_object_add_shared_fence, remove > reservation_object seq number I just undid these. Probably better to respin without the headline feature being immediately reverted :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock
Chris Wilson writes:
> If we only call process_csb() from the tasklet, though we lose the
> ability to bypass ksoftirqd interrupt processing on direct submission
> paths, we can push it out of the irq-off spinlock.
>
> The penalty is that we then allow schedule_out to be called concurrently
> with schedule_in requiring us to handle the usage count (baked into the
> pointer itself) atomically.
>
> As we do kick the tasklets (via local_bh_enable()) after our submission,
> there is a possibility there to see if we can pull the local softirq
> processing back from the ksoftirqd.
>
> v2: Store the 'switch_priority_hint' on submission, so that we can
> safely check during process_csb().
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 ++
> drivers/gpu/drm/i915/gt/intel_lrc.c | 136 +++---
> drivers/gpu/drm/i915/i915_utils.h | 20 ++-
> 5 files changed, 108 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> b/drivers/gpu/drm/i915/gt/intel_context_types.h
> index a632b20ec4d8..d8ce266c049f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> @@ -41,9 +41,7 @@ struct intel_context {
> struct intel_engine_cs *engine;
> struct intel_engine_cs *inflight;
> #define intel_context_inflight(ce) ptr_mask_bits((ce)->inflight, 2)
> -#define intel_context_inflight_count(ce) ptr_unmask_bits((ce)->inflight, 2)
> -#define intel_context_inflight_inc(ce) ptr_count_inc(&(ce)->inflight)
> -#define intel_context_inflight_dec(ce) ptr_count_dec(&(ce)->inflight)
> +#define intel_context_inflight_count(ce) ptr_unmask_bits((ce)->inflight, 2)
>
> struct i915_address_space *vm;
> struct i915_gem_context *gem_context;
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 957f27a2ec97..ba457c1c7dc0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1459,7 +1459,7 @@ int intel_enable_engine_stats(struct intel_engine_cs
> *engine)
>
> for (port = execlists->pending; (rq = *port); port++) {
> /* Exclude any contexts already counted in active */
> - if (intel_context_inflight_count(rq->hw_context) == 1)
> + if (!intel_context_inflight_count(rq->hw_context))
> engine->stats.active++;
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 9965a32601d6..5441aa9cb863 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -204,6 +204,16 @@ struct intel_engine_execlists {
>*/
> unsigned int port_mask;
>
> + /**
> + * @switch_priority_hint: Second context priority.
> + *
> + * We submit multiple contexts to the HW simultaneously and would
> + * like to occasionally switch between them to emulate timeslicing.
> + * To know when timeslicing is suitable, we track the priority of
> + * the context submitted second.
> + */
> + int switch_priority_hint;
> +
> /**
>* @queue_priority_hint: Highest pending priority.
>*
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index e9863f4d826b..8cb8c5303f42 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -547,27 +547,39 @@ execlists_context_status_change(struct i915_request
> *rq, unsigned long status)
> status, rq);
> }
>
> +static inline struct intel_engine_cs *
> +__execlists_schedule_in(struct i915_request *rq)
> +{
> + struct intel_engine_cs * const engine = rq->engine;
> + struct intel_context * const ce = rq->hw_context;
> +
> + intel_context_get(ce);
> +
> + intel_gt_pm_get(engine->gt);
> + execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
> + intel_engine_context_in(engine);
> +
> + return engine;
> +}
> +
> static inline struct i915_request *
> execlists_schedule_in(struct i915_request *rq, int idx)
> {
> - struct intel_context *ce = rq->hw_context;
> - int count;
> + struct intel_context * const ce = rq->hw_context;
> + struct intel_engine_cs *old;
>
> + GEM_BUG_ON(!intel_engine_pm_is_awake(rq->engine));
> trace_i915_request_in(rq, idx);
>
> - count = intel_context_inflight_count(ce);
> - if (!count) {
> - intel_context_get(ce);
> - ce->inflight = rq->engine;
> -
> - intel_gt_pm_get(ce->inflight->gt);
> - execlists_context_status_change(rq,
[Intel-gfx] [PULL] drm-misc-next
Hi Daniel, Dave, Here's this week drm-misc-next PR. Maxime drm-misc-next-2019-08-16: drm-misc-next for 5.4: UAPI Changes: Cross-subsystem Changes: Core Changes: - dma-buf: add reservation_object_fences helper, relax reservation_object_add_shared_fence, remove reservation_object seq number Driver Changes: - More dt-bindings YAML conversions - More removal of drmP.h includes - dw-hdmi: Support get_eld and various i2s improvements - gm12u320: Few fixes - meson: Global cleanup - panfrost: Few refactors, Support for GPU heap allocations - sun4i: Support for DDC enable GPIO - New panels: TI nspire, NEC NL8048HL11, LG Philips LB035Q02, Sharp LS037V7DW01, Sony ACX565AKM, Toppoly TD028TTEC1 Toppoly TD043MTEA1 The following changes since commit cc8f12996e24b102a086a253055ecc58c437c31d: drm/rockchip: fix VOP_WIN_GET macro (2019-08-08 00:23:15 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-08-16 for you to fetch changes up to dc2e1e5b279966affbd11ff7cfef52eb634ca2c9: drm/panel: Add driver for the Toppoly TD043MTEA1 panel (2019-08-14 22:23:11 +0200) drm-misc-next for 5.4: UAPI Changes: Cross-subsystem Changes: Core Changes: - dma-buf: add reservation_object_fences helper, relax reservation_object_add_shared_fence, remove reservation_object seq number Driver Changes: - More dt-bindings YAML conversions - More removal of drmP.h includes - dw-hdmi: Support get_eld and various i2s improvements - gm12u320: Few fixes - meson: Global cleanup - panfrost: Few refactors, Support for GPU heap allocations - sun4i: Support for DDC enable GPIO - New panels: TI nspire, NEC NL8048HL11, LG Philips LB035Q02, Sharp LS037V7DW01, Sony ACX565AKM, Toppoly TD028TTEC1 Toppoly TD043MTEA1 Chris Wilson (3): dma-fence: Propagate errors to dma-fence-array container dma-fence: Report the composite sync_file status dma-buf/sw_sync: Synchronize signal vs syncpt free Christian König (6): dma-buf: make dma_fence structure a bit smaller v2 dma-buf: add reservation_object_fences helper drm/i915: use new reservation_object_fences helper dma-buf: further relax reservation_object_add_shared_fence dma-buf: nuke reservation_object seq number dma-buf: rename reservation_object to dma_resv Geert Uytterhoeven (1): drm/bridge: dumb-vga-dac: Fix dereferencing -ENODEV DDC channel Gustavo A. R. Silva (1): drm/komeda: Fix potential integer overflow in komeda_crtc_update_clock_ratio Hans de Goede (4): drm: gm12u320: Some minor cleanups drm: gm12u320: Use DRM_DEV_ERROR everywhere drm: gm12u320: Do not take a mutex from a wait_event condition drm: gm12u320: Add -ENODEV to list of errors to ignore Jason Ekstrand (1): drm/syncobj: Add better overview documentation for syncobj (v2) Jerome Brunet (8): drm/bridge: dw-hdmi-i2s: support more i2s format drm/bridge: dw-hdmi: move audio channel setup out of ahb drm/bridge: dw-hdmi: set channel count in the infoframes drm/bridge: dw-hdmi-i2s: enable lpcm multi channels drm/bridge: dw-hdmi-i2s: set the channel allocation drm/bridge: dw-hdmi-i2s: reset audio fifo before applying new params drm/bridge: dw-hdmi-i2s: enable only the required i2s lanes drm/bridge: dw-hdmi-i2s: add .get_eld support Julien Masson (9): drm: meson: mask value when writing bits relaxed drm: meson: crtc: use proper macros instead of magic constants drm: meson: drv: use macro when initializing vpu drm: meson: vpp: use proper macros instead of magic constants drm: meson: viu: use proper macros instead of magic constants drm: meson: venc: use proper macros instead of magic constants drm: meson: global clean-up drm: meson: add macro used to enable HDMI PLL drm: meson: venc: set the correct macrovision max amplitude value Laurent Pinchart (9): dt-bindings: Add vendor prefix for LG Display dt-bindings: Add legacy 'toppoly' vendor prefix dt-bindings: display: panel: Add bindings for NEC NL8048HL11 panel drm/panel: Add driver for the LG Philips LB035Q02 panel drm/panel: Add driver for the NEC NL8048HL11 panel drm/panel: Add driver for the Sharp LS037V7DW01 panel drm/panel: Add driver for the Sony ACX565AKM panel drm/panel: Add driver for the Toppoly TD028TTEC1 panel drm/panel: Add driver for the Toppoly TD043MTEA1 panel Linus Walleij (3): drm/pl111: Support grayscale drm/panel: simple: Add TI nspire panel bindings drm/panel: simple: Support TI nspire panels Neil Armstrong (3): dt-bindings: display: amlogic,
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock
Quoting Patchwork (2019-08-16 12:26:55) > * igt@gem_sync@basic-store-each: > - fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/fi-cfl-8109u/igt@gem_s...@basic-store-each.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14048/fi-cfl-8109u/igt@gem_s...@basic-store-each.html Hmm, you were unconvinced by the new enable_timeslice() -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock
== Series Details == Series: series starting with [1/3] drm/i915/execlists: Lift process_csb() out of the irq-off spinlock URL : https://patchwork.freedesktop.org/series/65294/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6716 -> Patchwork_14048 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14048 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14048, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14048/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14048: ### IGT changes ### Possible regressions * igt@gem_sync@basic-store-each: - fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/fi-cfl-8109u/igt@gem_s...@basic-store-each.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14048/fi-cfl-8109u/igt@gem_s...@basic-store-each.html Known issues Here are the changes found in Patchwork_14048 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@basic-small-bo-tiledx: - fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledx.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14048/fi-icl-u3/igt@gem_mmap_...@basic-small-bo-tiledx.html * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: [PASS][5] -> [SKIP][6] ([fdo#109271] / [fdo#109278]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14048/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html Possible fixes * igt@gem_exec_reloc@basic-write-gtt: - fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14048/fi-icl-u3/igt@gem_exec_re...@basic-write-gtt.html * igt@i915_selftest@live_execlists: - fi-skl-gvtdvm: [DMESG-FAIL][9] ([fdo#08]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14048/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html - fi-bwr-2160:[DMESG-WARN][11] ([fdo#15]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/fi-bwr-2160/igt@i915_selftest@live_execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14048/fi-bwr-2160/igt@i915_selftest@live_execlists.html * igt@i915_selftest@live_hangcheck: - fi-bwr-2160:[DMESG-FAIL][13] ([fdo#15]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/fi-bwr-2160/igt@i915_selftest@live_hangcheck.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14048/fi-bwr-2160/igt@i915_selftest@live_hangcheck.html * igt@i915_selftest@live_requests: - fi-byt-j1900: [INCOMPLETE][15] ([fdo#102657]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6716/fi-byt-j1900/igt@i915_selftest@live_requests.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14048/fi-byt-j1900/igt@i915_selftest@live_requests.html [fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08 [fdo#15]: https://bugs.freedesktop.org/show_bug.cgi?id=15 Participating hosts (54 -> 46) -- Additional (1): fi-cfl-8700k Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6716 -> Patchwork_14048 CI-20190529: 20190529 CI_DRM_6716: 64ecd8f88d7b55de82ff414784ae4daca93d0577 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14048: 41bdc71c13f216b0ba5878af9888c3ee938443f8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 41bdc71c13f2 drm/i915: Markup expected timeline locks for i915_active
Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations
On Fri, 16 Aug 2019 13:21:03 +0200, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2019-08-16 11:54:58)
+static inline bool __check_layout(struct drm_i915_private *i915, u32
wopcm_size,
+ u32 guc_wopcm_base, u32
guc_wopcm_size,
+ u32 guc_fw_size, u32 huc_fw_size)
+{
+ const u32 ctx_rsvd = context_reserved_size(i915);
+ u32 size;
+
+ size = wopcm_size - ctx_rsvd;
I didn't spot the paranoia for
if (ctx_rsvd > wopcm_size)
return false;
Is that built in earlier? Even so, probably still wise to include it here
as well to fit in with the overflow checks.
was added to intel_wopcm_init() that calls this function, look for:
+ GEM_BUG_ON(ctx_rsvd + WOPCM_RESERVED_SIZE >= wopcm->size);
+ if (unlikely(range_overflows(guc_wopcm_base, guc_wopcm_size,
size))) {
+ dev_err(i915->drm.dev,
+ "WOPCM: invalid GuC region layout: %uK + %uK >
%uK\n",
+ guc_wopcm_base / SZ_1K, guc_wopcm_size / SZ_1K,
+ size / SZ_1K);
+ return false;
+ }
+
+ size = guc_fw_size + GUC_WOPCM_RESERVED +
GUC_WOPCM_STACK_RESERVED;
+ if (unlikely(guc_wopcm_size < size)) {
+ dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK <
%uK\n",
+ intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_GUC),
+ guc_wopcm_size / SZ_1K, size / SZ_1K);
+ return false;
+ }
+
+ size = huc_fw_size + WOPCM_RESERVED_SIZE;
+ if (unlikely(guc_wopcm_base < size)) {
+ dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK <
%uK\n",
+ intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
+ guc_wopcm_base / SZ_1K, size / SZ_1K);
+ return false;
+ }
+
+ return check_hw_restrictions(i915, guc_wopcm_base,
guc_wopcm_size,
+huc_fw_size);
}
Looks safely paranoid to me,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations
Quoting Michal Wajdeczko (2019-08-16 11:54:58)
> +static inline bool __check_layout(struct drm_i915_private *i915, u32
> wopcm_size,
> + u32 guc_wopcm_base, u32 guc_wopcm_size,
> + u32 guc_fw_size, u32 huc_fw_size)
> +{
> + const u32 ctx_rsvd = context_reserved_size(i915);
> + u32 size;
> +
> + size = wopcm_size - ctx_rsvd;
I didn't spot the paranoia for
if (ctx_rsvd > wopcm_size)
return false;
Is that built in earlier? Even so, probably still wise to include it here
as well to fit in with the overflow checks.
> + if (unlikely(range_overflows(guc_wopcm_base, guc_wopcm_size, size))) {
> + dev_err(i915->drm.dev,
> + "WOPCM: invalid GuC region layout: %uK + %uK > %uK\n",
> + guc_wopcm_base / SZ_1K, guc_wopcm_size / SZ_1K,
> + size / SZ_1K);
> + return false;
> + }
> +
> + size = guc_fw_size + GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
> + if (unlikely(guc_wopcm_size < size)) {
> + dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
> + intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_GUC),
> + guc_wopcm_size / SZ_1K, size / SZ_1K);
> + return false;
> + }
> +
> + size = huc_fw_size + WOPCM_RESERVED_SIZE;
> + if (unlikely(guc_wopcm_base < size)) {
> + dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
> + intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
> + guc_wopcm_base / SZ_1K, size / SZ_1K);
> + return false;
> + }
> +
> + return check_hw_restrictions(i915, guc_wopcm_base, guc_wopcm_size,
> +huc_fw_size);
> }
Looks safely paranoid to me,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
