Re: [Intel-gfx] [PATCH v4 01/18] drm/sched: Split drm_sched_job_init
On Tue, Jul 13, 2021 at 8:40 AM Christian König wrote: > > Am 12.07.21 um 19:53 schrieb Daniel Vetter: > > This is a very confusingly named function, because not just does it > > init an object, it arms it and provides a point of no return for > > pushing a job into the scheduler. It would be nice if that's a bit > > clearer in the interface. > > > > But the real reason is that I want to push the dependency tracking > > helpers into the scheduler code, and that means drm_sched_job_init > > must be called a lot earlier, without arming the job. > > > > v2: > > - don't change .gitignore (Steven) > > - don't forget v3d (Emma) > > > > v3: Emma noticed that I leak the memory allocated in > > drm_sched_job_init if we bail out before the point of no return in > > subsequent driver patches. To be able to fix this change > > drm_sched_job_cleanup() so it can handle being called both before and > > after drm_sched_job_arm(). > > > > Also improve the kerneldoc for this. > > > > v4: > > - Fix the drm_sched_job_cleanup logic, I inverted the booleans, as > >usual (Melissa) > > > > - Christian pointed out that drm_sched_entity_select_rq() also needs > >to be moved into drm_sched_job_arm, which made me realize that the > >job->id definitely needs to be moved too. > > As far as I can see you still have drm_sched_entity_select_rq() in > drm_sched_job_init()? Yeah it's again in there, but everything else which changes entity->rq state isn't in there anymore, but in job_arm(). I also checked the cleanup code, and we only update entity state in there, not job state, so there's no additional complications for cleanup. Of course this is quite a bit earlier, than if we do it in job_arm(), but also not fundamentally a new race window. Just a bigger one, so assuming the current code is correct, should be all fine. But also, very possible I missed something else again :-) -Daniel > Christian. > > > > >Shuffle things to fit between job_init and job_arm. > > > > v5: > > Reshuffle the split between init/arm once more, amdgpu abuses > > drm_sched.ready to signal gpu reset failures. Also document this > > somewhat. (Christian) > > > > Cc: Melissa Wen > > Acked-by: Steven Price (v2) > > Signed-off-by: Daniel Vetter > > Cc: Lucas Stach > > Cc: Russell King > > Cc: Christian Gmeiner > > Cc: Qiang Yu > > Cc: Rob Herring > > Cc: Tomeu Vizoso > > Cc: Steven Price > > Cc: Alyssa Rosenzweig > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Sumit Semwal > > Cc: "Christian König" > > Cc: Masahiro Yamada > > Cc: Kees Cook > > Cc: Adam Borowski > > Cc: Nick Terrell > > Cc: Mauro Carvalho Chehab > > Cc: Paul Menzel > > Cc: Sami Tolvanen > > Cc: Viresh Kumar > > Cc: Alex Deucher > > Cc: Dave Airlie > > Cc: Nirmoy Das > > Cc: Deepak R Varma > > Cc: Lee Jones > > Cc: Kevin Wang > > Cc: Chen Li > > Cc: Luben Tuikov > > Cc: "Marek Olšák" > > Cc: Dennis Li > > Cc: Maarten Lankhorst > > Cc: Andrey Grodzovsky > > Cc: Sonny Jiang > > Cc: Boris Brezillon > > Cc: Tian Tao > > Cc: etna...@lists.freedesktop.org > > Cc: l...@lists.freedesktop.org > > Cc: linux-me...@vger.kernel.org > > Cc: linaro-mm-...@lists.linaro.org > > Cc: Emma Anholt > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 + > > drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 + > > drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 + > > drivers/gpu/drm/lima/lima_sched.c| 2 + > > drivers/gpu/drm/panfrost/panfrost_job.c | 2 + > > drivers/gpu/drm/scheduler/sched_entity.c | 6 +-- > > drivers/gpu/drm/scheduler/sched_fence.c | 19 --- > > drivers/gpu/drm/scheduler/sched_main.c | 69 > > drivers/gpu/drm/v3d/v3d_gem.c| 2 + > > include/drm/gpu_scheduler.h | 7 ++- > > 10 files changed, 91 insertions(+), 22 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > index c5386d13eb4a..a4ec092af9a7 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > @@ -1226,6 +1226,8 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser > > *p, > > if (r) > > goto error_unlock; > > > > + drm_sched_job_arm(&job->base); > > + > > /* No memory allocation is allowed while holding the notifier lock. > >* The lock is held until amdgpu_cs_submit is finished and fence is > >* added to BOs. > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c > > index d33e6d97cc89..5ddb955d2315 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c > > @@ -170,6 +170,8 @@ int amdgpu_job_submit(struct amdgpu_job *job, struct > > drm_sched_entity *entity, > > if (r) > > return r; > > > > + drm_sched_job_arm(&job->base); > > + > > *f = dma_fence_get(&job->base.s_fence->finished); > > amdgpu_job_free_r
Re: [Intel-gfx] [PATCH v4 02/18] drm/sched: Barriers are needed for entity->last_scheduled
On Tue, Jul 13, 2021 at 8:35 AM Christian König wrote: > > Am 12.07.21 um 19:53 schrieb Daniel Vetter: > > It might be good enough on x86 with just READ_ONCE, but the write side > > should then at least be WRITE_ONCE because x86 has total store order. > > > > It's definitely not enough on arm. > > > > Fix this proplery, which means > > - explain the need for the barrier in both places > > - point at the other side in each comment > > > > Also pull out the !sched_list case as the first check, so that the > > code flow is clearer. > > > > While at it sprinkle some comments around because it was very > > non-obvious to me what's actually going on here and why. > > > > Note that we really need full barriers here, at first I thought > > store-release and load-acquire on ->last_scheduled would be enough, > > but we actually requiring ordering between that and the queue state. > > > > v2: Put smp_rmp() in the right place and fix up comment (Andrey) > > > > Signed-off-by: Daniel Vetter > > Cc: "Christian König" > > Cc: Steven Price > > Cc: Daniel Vetter > > Cc: Andrey Grodzovsky > > Cc: Lee Jones > > Cc: Boris Brezillon > > --- > > drivers/gpu/drm/scheduler/sched_entity.c | 27 ++-- > > 1 file changed, 25 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/scheduler/sched_entity.c > > b/drivers/gpu/drm/scheduler/sched_entity.c > > index f7347c284886..89e3f6eaf519 100644 > > --- a/drivers/gpu/drm/scheduler/sched_entity.c > > +++ b/drivers/gpu/drm/scheduler/sched_entity.c > > @@ -439,8 +439,16 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct > > drm_sched_entity *entity) > > dma_fence_set_error(&sched_job->s_fence->finished, > > -ECANCELED); > > > > dma_fence_put(entity->last_scheduled); > > + > > entity->last_scheduled = dma_fence_get(&sched_job->s_fence->finished); > > > > + /* > > + * If the queue is empty we allow drm_sched_entity_select_rq() to > > + * locklessly access ->last_scheduled. This only works if we set the > > + * pointer before we dequeue and if we a write barrier here. > > + */ > > + smp_wmb(); > > + > > Again, conceptual those barriers should be part of the spsc_queue > container and not externally. That would be extremely unusual api. Let's assume that your queue is very dumb, and protected by a simple lock. That's about the maximum any user could expect. But then you still need barriers here, because linux locks (spinlock, mutex) are defined to be one-way barriers: Stuff that's inside is guaranteed to be done insinde, but stuff outside of the locked region can leak in. They're load-acquire/store-release barriers. So not good enough. You really need to have barriers here, and they really all need to be documented properly. And yes that's a shit-ton of work in drm/sched, because it's full of yolo lockless stuff. The other case you could make is that this works like a wakeup queue, or similar. The rules there are: - wake_up (i.e. pushing something into the queue) is a store-release barrier - the waked up (i.e. popping an entry) is a load acquire barrier Which is obviuosly needed because otherwise you don't have coherency for the data queued up. And again not the barriers you're locking for here. Either way, we'd still need the comments, because it's still lockless trickery, and every single one of that needs to have a comment on both sides to explain what's going on. Essentially replace spsc_queue with an llist underneath, and that's the amount of barriers a data structure should provide. Anything else is asking your datastructure to paper over bugs in your users. This is similar to how atomic_t is by default completely unordered, and users need to add barriers as needed, with comments. I think this is all to make sure people don't just write lockless algorithms because it's a cool idea, but are forced to think this all through. Which seems to not have happened very consistently for drm/sched, so I guess needs to be fixed. I'm definitely not going to hide all that by making the spsc_queue stuff provide random unjustified barriers just because that would paper over drm/sched bugs. We need to fix the actual bugs, and preferrable all of them. I've found a few, but I wasn't involved in drm/sched thus far, so best I can do is discover them as we go. -Daniel > Regards, > Christian. > > > spsc_queue_pop(&entity->job_queue); > > return sched_job; > > } > > @@ -459,10 +467,25 @@ void drm_sched_entity_select_rq(struct > > drm_sched_entity *entity) > > struct drm_gpu_scheduler *sched; > > struct drm_sched_rq *rq; > > > > - if (spsc_queue_count(&entity->job_queue) || !entity->sched_list) > > + /* single possible engine and already selected */ > > + if (!entity->sched_list) > > + return; > > + > > + /* queue non-empty, stay on the same engine */ > > + if (spsc_queue_count(&entity->job_queue)) > > return; > > > > - fe
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/6] drm/i915/display: Settle on "adl-x" in WA comments
== Series Details == Series: series starting with [CI,1/6] drm/i915/display: Settle on "adl-x" in WA comments URL : https://patchwork.freedesktop.org/series/92457/ State : success == Summary == CI Bug Log - changes from CI_DRM_10335_full -> Patchwork_20581_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20581_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#658]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-iclb2/igt@feature_discov...@psr2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-iclb5/igt@feature_discov...@psr2.html * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#146] / [i915#198]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-skl3/igt@gem_ctx_isolation@preservation...@vcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-skl1/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2410]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-glk3/igt@gem_exec_f...@basic-deadline.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-glk7/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][10] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-apl2/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2842]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-tglb: [PASS][18] -> [FAIL][19] ([i915#2842]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-tglb6/igt@gem_exec_fair@basic-p...@vecs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-tglb6/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][20] ([i915#3633]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_mmap_gtt@big-copy-odd: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#307]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-glk5/igt@gem_mmap_...@big-copy-odd.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-glk6/igt@gem_mmap_...@big-copy-odd.html * igt@gem_mmap_gtt@cpuset-big-copy: - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#307]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/shard-iclb4/igt@gem_mmap_...@cpuset-big-copy.html * igt@gem_mmap_offset@clear: - shard-skl: [PASS][25] -> [FAIL][26] ([i915#3160]) [25]: https://
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/uapi: reject set_domain for discrete
On Friday, July 2, 2021 12:22:58 PM PDT Daniel Vetter wrote: > On Fri, Jul 02, 2021 at 03:31:08PM +0100, Tvrtko Ursulin wrote: > > > > On 01/07/2021 16:10, Matthew Auld wrote: > > > The CPU domain should be static for discrete, and on DG1 we don't need > > > any flushing since everything is already coherent, so really all this > > > > Knowledge of the write combine buffer is assumed to be had by anyone > > involved? > > > > > does is an object wait, for which we have an ioctl. Longer term the > > > desired caching should be an immutable creation time property for the > > > BO, which can be set with something like gem_create_ext. > > > > > > One other user is iris + userptr, which uses the set_domain to probe all > > > the pages to check if the GUP succeeds, however keeping the set_domain > > > around just for that seems rather scuffed. We could equally just submit > > > a dummy batch, which should hopefully be good enough, otherwise adding a > > > new creation time flag for userptr might be an option. Although longer > > > term we will also have vm_bind, which should also be a nice fit for > > > this, so adding a whole new flag is likely overkill. > > > > Execbuf sounds horrible. But it all reminds me of past work by Chris which > > is surprisingly hard to find in the archives. Patches like: > > > > commit 7706a433388016983052a27c0fd74a64b1897ae7 > > Author: Chris Wilson > > Date: Wed Nov 8 17:04:07 2017 + > > > > drm/i915/userptr: Probe existence of backing struct pages upon creation > > Jason Ekstrand requested a more efficient method than userptr+set-domain > > to determine if the userptr object was backed by a complete set of pages > > upon creation. To be more efficient than simply populating the userptr > > using get_user_pages() (as done by the call to set-domain or execbuf), > > we can walk the tree of vm_area_struct and check for gaps or vma not > > backed by struct page (VM_PFNMAP). The question is how to handle > > VM_MIXEDMAP which may be either struct page or pfn backed... > > > > commit 7ca21d3390eec23db99b8131ed18bc036efaba18 > > Author: Chris Wilson > > Date: Wed Nov 8 17:48:22 2017 + > > > > drm/i915/userptr: Add a flag to populate the userptr on creation > > Acquiring the backing struct pages for the userptr range is not free; > > the first client for userptr would insist on frequently creating userptr > > objects ahead of time and not use them. For that first client, deferring > > the cost of populating the userptr (calling get_user_pages()) to the > > actual execbuf was a substantial improvement. However, not all clients > > are the same, and most would like to validate that the userptr is valid > > and backed by struct pages upon creation, so offer a > > I915_USERPTR_POPULATE flag to do just that. > > Note that big difference between I915_USERPTR_POPULATE and the deferred > > scheme is that POPULATE is guaranteed to be synchronous, the result is > > known before the ioctl returns (and the handle exposed). However, due to > > system memory pressure, the object may be paged out before use, > > requiring them to be paged back in on execbuf (as may always happen). > > > > At least with the first one I think I was skeptical, since probing at > > point A makes a weak test versus userptr getting used at point B. > > Populate is kind of same really when user controls the backing store. At > > least these two arguments I think stand if we are trying to sell these > > flags as validation. But if the idea is limited to pure preload, with no > > guarantees that it keeps working by time of real use, then I guess it > > may be passable. > > Well we've thrown this out again because there was no userspace. But if > this is requested by mesa, then the _PROBE flag should be entirely > sufficient. > > Since I don't want to hold up dg1 pciids on this it'd be nice if we could > just go ahead with the dummy batch, if Ken/Jordan don't object - iris is > the only umd that needs this. I really would rather not have to submit a dummy batchbuffer. The GL_AMD_pinned_memory extension requires throwing an error when performing the initial userptr import if "the store cannot be mapped to the GPU address space". So this is not a weird thing that iris is doing, it's part of the actual API we're implementing. Today, I can use SET_DOMAIN which is almost no code. In the future, I'll have VM_BIND, which also makes sense. In the meantime, this is taking away my easy implementation for a bunch of code that I have to keep supporting forever. >From the point of view of having a clean API... - Using SET_DOMAIN is clearly a hack. It works, but we're not intending to do anything with cache domains. Dropping this API is a good plan. - Passing a flag to USERPTR that says "please actually make sure it works" seems entirely reasonable to have as part of the API, and matches our userspace API. - Using
[Intel-gfx] ✗ Fi.CI.BUILD: failure for iommu/vt-d: Disable igfx iommu superpage on bxt/skl/glk (rev2)
== Series Details == Series: iommu/vt-d: Disable igfx iommu superpage on bxt/skl/glk (rev2) URL : https://patchwork.freedesktop.org/series/92374/ State : failure == Summary == Applying: iommu/vt-d: Disable superpage for Geminilake igfx error: corrupt patch at line 14 error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 iommu/vt-d: Disable superpage for Geminilake igfx 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] [RFC PATCH v2 1/4] drm_print.h: rewrap __DRM_DEFINE_DBG_RATELIMITED macro
On Sun, Jul 11, 2021 at 10:17 AM Joe Perches wrote:
>
> On Sat, 2021-07-10 at 23:49 -0600, Jim Cromie wrote:
> > whitespace only, to diff-minimize a later commit.
> > no functional changes
> []
> > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> []
> > @@ -524,19 +524,24 @@ void __drm_err(const char *format, ...);
> > #define DRM_DEBUG_DP(fmt, ...)
> > \
> > __drm_dbg(DRM_UT_DP, fmt, ## __VA_ARGS__)
> >
> >
> > -#define __DRM_DEFINE_DBG_RATELIMITED(category, drm, fmt, ...)
> > \
> > -({
> > \
> > - static DEFINE_RATELIMIT_STATE(rs_, DEFAULT_RATELIMIT_INTERVAL,
> > DEFAULT_RATELIMIT_BURST);\
> > - const struct drm_device *drm_ = (drm);
> > \
> > -
> > \
> > - if (drm_debug_enabled(DRM_UT_ ## category) && __ratelimit(&rs_))
> > \
> > - drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ##
> > __VA_ARGS__); \
> > +#define __DRM_DEFINE_DBG_RATELIMITED(category, drm, fmt, ...)
> > \
> > +({ \
> > + static DEFINE_RATELIMIT_STATE(rs_, \
> > + DEFAULT_RATELIMIT_INTERVAL, \
> > + DEFAULT_RATELIMIT_BURST); \
> > + const struct drm_device *drm_ = (drm); \
> > + \
> > + if (drm_debug_enabled(DRM_UT_ ## category) \
> > + && __ratelimit(&rs_)) \
>
> Though I don't really see the need for the change, the typical style
> has the logical continuation at the end of the test.
>
yes I caught that late, old habit, hard to break.
That if-statement is altered as part of HEAD+2
drm: RFC add choice to use dynamic debug in drm-debug
which replaces drm_dev_printk with drm_dev_dbg
(which calls pr_debug in DRM_USE_DYNAMIC_DEBUG)
> if (drm_debug_enabled(DRM_UT_ ## category) && \
> __ratelimit(&rs_)) \
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] iommu/vt-d: Disable superpage for Geminilake igfx
On 7/12/21 11:47 PM, Ville Syrjälä wrote:
On Mon, Jul 12, 2021 at 07:23:07AM +0800, Lu Baolu wrote:
On 7/10/21 12:47 AM, Ville Syrjala wrote:
From: Ville Syrjälä
While running "gem_exec_big --r single" from igt-gpu-tools on
Geminilake as soon as a 2M mapping is made I tend to get a DMAR
write fault. Strangely the faulting address is always a 4K page
and usually very far away from the 2M page that got mapped.
But if no 2M mappings get used I can't reproduce the fault.
I also tried to dump the PTE for the faulting address but it actually
looks correct to me (ie. definitely seems to have the write bit set):
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Write] Request device [00:02.0] PASID fault addr
7fa8a78000 [fault reason 05] PTE Write access is not set
DMAR: fault 7fa8a78000 (level=1) PTE = 149efc003
So not really sure what's going on and this might just be full on duct
tape, but it seems to work here. The machine has now survived a whole day
running that test whereas with superpage enabled it fails in less than
a minute usually.
TODO: might be nice to disable superpage only for the igfx iommu
instead of both iommus
If all these quirks are about igfx dedicated iommu's, I would suggest to
disable superpage only for the igfx ones.
Sure. Unfortunately there's no convenient mechanism to do that in
the iommu driver that I can immediately see. So not something I
can just whip up easily. Since you're actually familiar with the
driver maybe you can come up with a decent solution for that?
How about something like below? [no compile, no test...]
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 1131b8efb050..2d51ef288a9e 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -338,6 +338,7 @@ static int intel_iommu_strict;
static int intel_iommu_superpage = 1;
static int iommu_identity_mapping;
static int iommu_skip_te_disable;
+static int iommu_skip_igfx_superpage;
#define IDENTMAP_GFX 2
#define IDENTMAP_AZALIA4
@@ -652,6 +653,27 @@ static bool domain_update_iommu_snooping(struct
intel_iommu *skip)
return ret;
}
+static bool domain_use_super_page(struct dmar_domain *domain)
+{
+ struct dmar_drhd_unit *drhd;
+ struct intel_iommu *iommu;
+ bool ret = true;
+
+ if (!intel_iommu_superpage)
+ return false;
+
+ rcu_read_lock();
+ for_each_active_iommu(iommu, drhd) {
+ if (drhd->gfx_dedicated && iommu_skip_igfx_superpage) {
+ ret = false;
+ break
+ }
+ }
+ rcu_read_unlock();
+
+ return ret;
+}
+
static int domain_update_iommu_superpage(struct dmar_domain *domain,
struct intel_iommu *skip)
{
@@ -659,7 +681,7 @@ static int domain_update_iommu_superpage(struct
dmar_domain *domain,
struct intel_iommu *iommu;
int mask = 0x3;
- if (!intel_iommu_superpage)
+ if (!domain_use_super_page(domain))
return 0;
/* set iommu_superpage to the smallest common denominator */
@@ -5656,6 +5678,14 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
0x1632, quirk_iommu_igfx);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163A, quirk_iommu_igfx);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx);
+static void quirk_skip_igfx_superpage(struct pci_dev *dev)
+{
+ pci_info(dev, "Disabling IOMMU superpage for graphics on this
chipset\n");
+ iommu_skip_igfx_superpage = 1;
+}
+
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x3184,
quirk_skip_igfx_superpage);
+
static void quirk_iommu_rwbf(struct pci_dev *dev)
{
if (risky_device(dev))
Best regards,
baolu
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/6] drm/i915/display: Settle on "adl-x" in WA comments
== Series Details == Series: series starting with [CI,1/6] drm/i915/display: Settle on "adl-x" in WA comments URL : https://patchwork.freedesktop.org/series/92457/ State : success == Summary == CI Bug Log - changes from CI_DRM_10335 -> Patchwork_20581 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/index.html Changes --- No changes found Participating hosts (40 -> 39) -- Missing(1): fi-bdw-samus Build changes - * Linux: CI_DRM_10335 -> Patchwork_20581 CI-20190529: 20190529 CI_DRM_10335: 6420d4c905cfd9a9098c7ab339992eafa628de4d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6134: cd63c83e23789eb194d38b8d272247a88122f2f6 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20581: bd02956b712bc812673a962faaba7c80d48115b4 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == bd02956b712b drm/i915/display/xelpd: Extend Wa_14011508470 fae190f45c0a drm/i915: Limit Wa_22010178259 to affected platforms fed313930af0 drm/i915/adl_s: Extend Wa_1406941453 a4cf4dd36f79 drm/i915: Implement Wa_1508744258 b6586d4050f6 drm/i915: Settle on "adl-x" in WA comments fb832381def1 drm/i915/display: Settle on "adl-x" in WA comments == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20581/index.html ___ 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 [1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf (v5)
== Series Details == Series: series starting with [1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf (v5) URL : https://patchwork.freedesktop.org/series/92454/ State : success == Summary == CI Bug Log - changes from CI_DRM_10335_full -> Patchwork_20580_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20580_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@psr2: - shard-iclb: [PASS][1] -> [SKIP][2] ([i915#658]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-iclb2/igt@feature_discov...@psr2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-iclb3/igt@feature_discov...@psr2.html * igt@gem_create@create-clear: - shard-skl: [PASS][3] -> [FAIL][4] ([i915#3160]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-skl1/igt@gem_cre...@create-clear.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-skl5/igt@gem_cre...@create-clear.html * igt@gem_ctx_persistence@legacy-engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([i915#146] / [i915#198]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-skl7/igt@gem_...@in-flight-suspend.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-skl3/igt@gem_...@in-flight-suspend.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#3063] / [i915#3648]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-tglb3/igt@gem_...@unwedge-stress.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-tglb1/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2846]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-glk3/igt@gem_exec_f...@basic-deadline.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-glk6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2842]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-iclb6/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_pread@exhaustion: - shard-skl: NOTRUN -> [WARN][17] ([i915#2658]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-skl2/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-apl1/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1436] / [i915#716]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-skl10/igt@gen9_exec_pa...@allowed-single.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-skl3/igt@gen9_exec_pa...@allowed-single.html * igt@gen9_exec_parse@batch-invalid-length: - shard-iclb: NOTRUN -> [SKIP][21] ([fdo#112306]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-iclb6/igt@gen9_exec_pa...@batch-invalid-length.html * igt@gen9_exec_parse@bb-large: - shard-skl: NOTRUN -> [FAIL][22] ([i915#3296]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-skl8/igt@gen9_exec_pa...@bb-large.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#454]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-iclb6/igt@i915_pm...@dc6-psr.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/shard-iclb4/igt@i915_pm...@dc6-psr.html * igt@kms_bi
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/6] drm/i915/display: Settle on "adl-x" in WA comments
== Series Details == Series: series starting with [CI,1/6] drm/i915/display: Settle on "adl-x" in WA comments URL : https://patchwork.freedesktop.org/series/92457/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type in assignment (different address spaces) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/16] drm/i915/guc/slpc: Lay out slpc init/enable/disable/fini
On 7/10/2021 7:35 AM, Michal Wajdeczko wrote:
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Declare header and source files for SLPC, along with init and
enable/disable function templates.
later you claim that "disable" is not needed
Changed.
Signed-off-by: Vinay Belgaumkar
Signed-off-by: Sundaresan Sujaritha
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 34 +
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 16 ++
4 files changed, 53 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index ab7679957623..d8eac4468df9 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -186,6 +186,7 @@ i915-y += gt/uc/intel_uc.o \
gt/uc/intel_guc_fw.o \
gt/uc/intel_guc_log.o \
gt/uc/intel_guc_log_debugfs.o \
+ gt/uc/intel_guc_slpc.o \
gt/uc/intel_guc_submission.o \
gt/uc/intel_huc.o \
gt/uc/intel_huc_debugfs.o \
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index e5a456918b88..0dbbd9cf553f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -15,6 +15,7 @@
#include "intel_guc_ct.h"
#include "intel_guc_log.h"
#include "intel_guc_reg.h"
+#include "intel_guc_slpc.h"
#include "intel_uc_fw.h"
#include "i915_utils.h"
#include "i915_vma.h"
@@ -30,6 +31,7 @@ struct intel_guc {
struct intel_uc_fw fw;
struct intel_guc_log log;
struct intel_guc_ct ct;
+ struct intel_guc_slpc slpc;
/* Global engine used to submit requests to GuC */
struct i915_sched_engine *sched_engine;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
new file mode 100644
index ..c1f569d2300d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -0,0 +1,34 @@
+/*
+ * SPDX-License-Identifier: MIT
SPDX tag shall be in very first line, for .c:
// SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2020 Intel Corporation
2021
done.
+ */
+
+#include "intel_guc_slpc.h"
+
+int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
+{
+ return 0;
+}
+
+/*
+ * intel_guc_slpc_enable() - Start SLPC
+ * @slpc: pointer to intel_guc_slpc.
+ *
+ * SLPC is enabled by setting up the shared data structure and
+ * sending reset event to GuC SLPC. Initial data is setup in
+ * intel_guc_slpc_init. Here we send the reset event. We do
+ * not currently need a slpc_disable since this is taken care
+ * of automatically when a reset/suspend occurs and the guc
s/guc/GuC
+ * channels are destroyed.
you mean CTB ?
yes, fixed.
+ *
+ * Return: 0 on success, non-zero error code on failure.
+ */
+int intel_guc_slpc_enable(struct intel_guc_slpc *slpc)
+{
+ return 0;
+}
+
+void intel_guc_slpc_fini(struct intel_guc_slpc *slpc)
+{
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
new file mode 100644
index ..74fd86769163
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h
@@ -0,0 +1,16 @@
+/*
+ * SPDX-License-Identifier: MIT
SPDX tag shall be in very first line, for .h:
/* SPDX-License-Identifier: MIT */
+ *
+ * Copyright © 2020 Intel Corporation
2021
+ */
+#ifndef _INTEL_GUC_SLPC_H_
+#define _INTEL_GUC_SLPC_H_
+
+struct intel_guc_slpc {
+};
move all data definitions to intel_guc_slpc_types.h and include it here
+
+int intel_guc_slpc_init(struct intel_guc_slpc *slpc);
+int intel_guc_slpc_enable(struct intel_guc_slpc *slpc);
+void intel_guc_slpc_fini(struct intel_guc_slpc *slpc);
+
+#endif
and as suggested in comment to 2/14 you should likely move this patch to
the front of the series
Yes, squashed with the first patch.
Thanks,
Vinay.
Michal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI 4/6] drm/i915/adl_s: Extend Wa_1406941453
BSpec: 54370
Cc: Gwan-gyeong Mun
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index c346229e2be00..72562c233ad20 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1677,8 +1677,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
GEN8_RC_SEMA_IDLE_MSG_DISABLE);
}
- if (IS_DG1(i915) || IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
- /* Wa_1406941453:tgl,rkl,dg1 */
+ if (IS_DG1(i915) || IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915) ||
+ IS_ALDERLAKE_S(i915)) {
+ /* Wa_1406941453:tgl,rkl,dg1,adl-s */
wa_masked_en(wal,
GEN10_SAMPLER_MODE,
ENABLE_SMALLPL);
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI 6/6] drm/i915/display/xelpd: Extend Wa_14011508470
This workaround is also applicable to xelpd display so extending it.
Cc: Gwan-gyeong Mun
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_power.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 6fc766da66054..d92db471411e5 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -5883,8 +5883,8 @@ static void icl_display_core_init(struct drm_i915_private
*dev_priv,
if (resume && intel_dmc_has_payload(dev_priv))
intel_dmc_load_program(dev_priv);
- /* Wa_14011508470 */
- if (DISPLAY_VER(dev_priv) == 12) {
+ /* Wa_14011508470:tgl,dg1,rkl,adl-s,adl-p */
+ if (DISPLAY_VER(dev_priv) >= 12) {
val = DCPR_CLEAR_MEMSTAT_DIS | DCPR_SEND_RESP_IMM |
DCPR_MASK_LPMODE | DCPR_MASK_MAXLATENCY_MEMUP_CLR;
intel_uncore_rmw(&dev_priv->uncore, GEN11_CHICKEN_DCPR_2, 0,
val);
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI 2/6] drm/i915: Settle on "adl-x" in WA comments
Most of the places are using this format so lets consolidate it.
v2:
- split patch in two: display and non-display because of conflicts
between drm-intel-gt-next x drm-intel-next
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index d9a5a445ceecd..e5e3f820074a9 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1078,7 +1078,7 @@ gen12_gt_workarounds_init(struct drm_i915_private *i915,
{
icl_wa_init_mcr(i915, wal);
- /* Wa_14011060649:tgl,rkl,dg1,adls,adl-p */
+ /* Wa_14011060649:tgl,rkl,dg1,adl-s,adl-p */
wa_14011060649(i915, wal);
}
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5fdb96e7d2668..0cbb79452fcf9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7356,7 +7356,7 @@ static void icl_init_clock_gating(struct drm_i915_private
*dev_priv)
static void gen12lp_init_clock_gating(struct drm_i915_private *dev_priv)
{
- /* Wa_1409120013:tgl,rkl,adl_s,dg1 */
+ /* Wa_1409120013:tgl,rkl,adl-s,dg1 */
if (IS_TIGERLAKE(dev_priv) || IS_ROCKETLAKE(dev_priv) ||
IS_ALDERLAKE_S(dev_priv) || IS_DG1(dev_priv))
intel_uncore_write(&dev_priv->uncore, ILK_DPFC_CHICKEN,
@@ -7367,7 +7367,7 @@ static void gen12lp_init_clock_gating(struct
drm_i915_private *dev_priv)
intel_uncore_write(&dev_priv->uncore, GEN9_CLKGATE_DIS_3,
intel_uncore_read(&dev_priv->uncore, GEN9_CLKGATE_DIS_3) |
TGL_VRH_GATING_DIS);
- /* Wa_14011059788:tgl,rkl,adl_s,dg1,adl-p */
+ /* Wa_14011059788:tgl,rkl,adl-s,dg1,adl-p */
intel_uncore_rmw(&dev_priv->uncore, GEN10_DFR_RATIO_EN_AND_CHICKEN,
0, DFR_DISABLE);
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI 5/6] drm/i915: Limit Wa_22010178259 to affected platforms
This workaround is not needed for platforms with display 13. Cc: Gwan-gyeong Mun Reviewed-by: Matt Roper Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_display_power.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index 285380079aab2..6fc766da66054 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -5822,10 +5822,11 @@ static void tgl_bw_buddy_init(struct drm_i915_private *dev_priv) intel_de_write(dev_priv, BW_BUDDY_PAGE_MASK(i), table[config].page_mask); - /* Wa_22010178259:tgl,rkl */ - intel_de_rmw(dev_priv, BW_BUDDY_CTL(i), -BW_BUDDY_TLB_REQ_TIMER_MASK, -BW_BUDDY_TLB_REQ_TIMER(0x8)); + /* Wa_22010178259:tgl,dg1,rkl,adl-s */ + if (DISPLAY_VER(dev_priv) == 12) + intel_de_rmw(dev_priv, BW_BUDDY_CTL(i), +BW_BUDDY_TLB_REQ_TIMER_MASK, +BW_BUDDY_TLB_REQ_TIMER(0x8)); } } } -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI 3/6] drm/i915: Implement Wa_1508744258
Same bit was required for Wa_14012131227 in DG1 now it is also required as Wa_1508744258 to TGL, RKL, DG1, ADL-S and ADL-P. Cc: Gwan-gyeong Mun Reviewed-by: Matt Roper Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index e5e3f820074a9..c346229e2be00 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -670,6 +670,13 @@ static void gen12_ctx_workarounds_init(struct intel_engine_cs *engine, FF_MODE2_GS_TIMER_MASK, FF_MODE2_GS_TIMER_224, 0); + + /* +* Wa_14012131227:dg1 +* Wa_1508744258:tgl,rkl,dg1,adl-s,adl-p +*/ + wa_masked_en(wal, GEN7_COMMON_SLICE_CHICKEN1, +GEN9_RHWO_OPTIMIZATION_DISABLE); } static void dg1_ctx_workarounds_init(struct intel_engine_cs *engine, -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI 1/6] drm/i915/display: Settle on "adl-x" in WA comments
Most of the places are using this format so lets consolidate it.
v2:
- split patch in two: display and non-display because of conflicts
between drm-intel-gt-next x drm-intel-next
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
drivers/gpu/drm/i915/display/intel_cursor.c| 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_psr.c | 10 +-
drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +-
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index df2d8ce4a12f6..71067a62264de 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2878,7 +2878,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
*dev_priv)
dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
- /* Wa_22011320316:adlp[a0] */
+ /* Wa_22011320316:adl-p[a0] */
if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0))
dev_priv->cdclk.table = adlp_a_step_cdclk_table;
else
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
b/drivers/gpu/drm/i915/display/intel_cursor.c
index bb61e736de911..f61a25fb87e90 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -383,7 +383,7 @@ static u32 i9xx_cursor_ctl(const struct intel_crtc_state
*crtc_state,
if (plane_state->hw.rotation & DRM_MODE_ROTATE_180)
cntl |= MCURSOR_ROTATE_180;
- /* Wa_22012358565:adlp */
+ /* Wa_22012358565:adl-p */
if (DISPLAY_VER(dev_priv) == 13)
cntl |= MCURSOR_ARB_SLOTS(1);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 026c28c612f07..65ddb6ca16e67 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -975,7 +975,7 @@ void intel_enable_pipe(const struct intel_crtc_state
*new_crtc_state)
/* FIXME: assert CPU port conditions for SNB+ */
}
- /* Wa_22012358565:adlp */
+ /* Wa_22012358565:adl-p */
if (DISPLAY_VER(dev_priv) == 13)
intel_de_rmw(dev_priv, PIPE_ARB_CTL(pipe),
0, PIPE_ARB_USE_PROG_SLOTS);
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 9643624fe160d..4dfe1dceb8635 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -545,7 +545,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
val |= EDP_PSR2_FRAME_BEFORE_SU(intel_dp->psr.sink_sync_latency + 1);
val |= intel_psr2_get_tp_time(intel_dp);
- /* Wa_22012278275:adlp */
+ /* Wa_22012278275:adl-p */
if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_D1)) {
static const u8 map[] = {
2, /* 5 lines */
@@ -733,7 +733,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp *intel_dp,
if (!dc3co_is_pipe_port_compatible(intel_dp, crtc_state))
return;
- /* Wa_16011303918:adlp */
+ /* Wa_16011303918:adl-p */
if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0))
return;
@@ -965,7 +965,7 @@ static bool intel_psr2_config_valid(struct intel_dp
*intel_dp,
return false;
}
- /* Wa_16011303918:adlp */
+ /* Wa_16011303918:adl-p */
if (crtc_state->vrr.enable &&
IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0)) {
drm_dbg_kms(&dev_priv->drm,
@@ -1160,7 +1160,7 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp)
intel_dp->psr.psr2_sel_fetch_enabled ?
IGNORE_PSR2_HW_TRACKING : 0);
- /* Wa_16011168373:adlp */
+ /* Wa_16011168373:adl-p */
if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) &&
intel_dp->psr.psr2_enabled)
intel_de_rmw(dev_priv,
@@ -1346,7 +1346,7 @@ static void intel_psr_disable_locked(struct intel_dp
*intel_dp)
intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
- /* Wa_16011168373:adlp */
+ /* Wa_16011168373:adl-p */
if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) &&
intel_dp->psr.psr2_enabled)
intel_de_rmw(dev_priv,
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
in
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf (v5)
== Series Details == Series: series starting with [1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf (v5) URL : https://patchwork.freedesktop.org/series/92454/ State : success == Summary == CI Bug Log - changes from CI_DRM_10335 -> Patchwork_20580 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/index.html Known issues Here are the changes found in Patchwork_20580 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7500u: [PASS][1] -> [DMESG-WARN][2] ([i915#2868]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868 Participating hosts (40 -> 39) -- Missing(1): fi-bdw-samus Build changes - * Linux: CI_DRM_10335 -> Patchwork_20580 CI-20190529: 20190529 CI_DRM_10335: 6420d4c905cfd9a9098c7ab339992eafa628de4d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6134: cd63c83e23789eb194d38b8d272247a88122f2f6 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20580: a353e0a7e001395d0afb278307622610add7244f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a353e0a7e001 drm/i915/gem: Migrate to system at dma-buf attach time (v5) 65b5bf0bcc7d drm/i915/gem: Correct the locking and pin pattern for dma-buf (v5) == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20580/index.html ___ 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/sched dependency tracking and dma-resv fixes (rev3)
== Series Details ==
Series: drm/sched dependency tracking and dma-resv fixes (rev3)
URL : https://patchwork.freedesktop.org/series/92333/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10335_full -> Patchwork_20579_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20579_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20579_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_20579_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_async@concurrent-writes@rcs0:
- shard-snb: NOTRUN -> [FAIL][1] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-snb5/igt@gem_exec_async@concurrent-wri...@rcs0.html
* igt@gem_exec_async@concurrent-writes@vcs0:
- shard-iclb: [PASS][2] -> [FAIL][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-iclb7/igt@gem_exec_async@concurrent-wri...@vcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-iclb1/igt@gem_exec_async@concurrent-wri...@vcs0.html
* igt@gem_exec_async@concurrent-writes@vcs1:
- shard-iclb: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-iclb1/igt@gem_exec_async@concurrent-wri...@vcs1.html
* igt@gem_exec_async@concurrent-writes@vecs0:
- shard-kbl: [PASS][5] -> [FAIL][6] +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-kbl1/igt@gem_exec_async@concurrent-wri...@vecs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-kbl2/igt@gem_exec_async@concurrent-wri...@vecs0.html
* igt@gem_exec_schedule@u-independent@rcs0:
- shard-tglb: [PASS][7] -> [FAIL][8] +5 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-tglb1/igt@gem_exec_schedule@u-independ...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-tglb6/igt@gem_exec_schedule@u-independ...@rcs0.html
* igt@gem_exec_whisper@basic-queues-all:
- shard-iclb: [PASS][9] -> [INCOMPLETE][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-iclb3/igt@gem_exec_whis...@basic-queues-all.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-iclb5/igt@gem_exec_whis...@basic-queues-all.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_async@concurrent-writes@rcs0:
- {shard-rkl}:[PASS][11] -> [FAIL][12] +2 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-rkl-5/igt@gem_exec_async@concurrent-wri...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-rkl-2/igt@gem_exec_async@concurrent-wri...@rcs0.html
Known issues
Here are the changes found in Patchwork_20579_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][13] -> [SKIP][14] ([i915#658])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-iclb2/igt@feature_discov...@psr2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-iclb7/igt@feature_discov...@psr2.html
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-kbl: NOTRUN -> [DMESG-WARN][15] ([i915#180]) +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-kbl3/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#180])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-apl2/igt@gem_ctx_isolation@preservation...@vcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-apl1/igt@gem_ctx_isolation@preservation...@vcs0.html
* igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#1099]) +1
similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html
* igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][19] -> [FAIL][20] ([i915#2410])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10335/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html
* igt@gem_exec_fair@basic-deadline:
- shard-apl:
Re: [Intel-gfx] [PATCH 02/16] drm/i915/guc/slpc: Initial definitions for slpc
On 7/10/2021 7:27 AM, Michal Wajdeczko wrote:
Hi Vinay,
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Add macros to check for slpc support. This feature is currently supported
for gen12+ and enabled whenever guc submission is enabled/selected.
please try to use consistent names across all patches:
s/slpc/SLPC
s/gen12/Gen12
s/guc/GuC
Ok.
Signed-off-by: Vinay Belgaumkar
Signed-off-by: Sundaresan Sujaritha
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 21 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 16 ++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 --
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 1 +
6 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 979128e28372..b9a809f2d221 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -157,6 +157,7 @@ void intel_guc_init_early(struct intel_guc *guc)
intel_guc_ct_init_early(&guc->ct);
intel_guc_log_init_early(&guc->log);
intel_guc_submission_init_early(guc);
+ intel_guc_slpc_init_early(guc);
mutex_init(&guc->send_mutex);
spin_lock_init(&guc->irq_lock);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 5d94cf482516..e5a456918b88 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -57,6 +57,8 @@ struct intel_guc {
bool submission_supported;
bool submission_selected;
+ bool slpc_supported;
+ bool slpc_selected;
struct i915_vma *ads_vma;
struct __guc_ads_blob *ads_blob;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9c102bf0c8e3..e2644a05f298 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2351,6 +2351,27 @@ void intel_guc_submission_init_early(struct intel_guc
*guc)
guc->submission_selected = __guc_submission_selected(guc);
}
+static bool __guc_slpc_supported(struct intel_guc *guc)
hmm, easy to confuse with intel_guc_slpc_is_supported, so maybe:
__detect_slpc_supported()
(yes, I know you were following code above)
+{
+ /* GuC slpc is unavailable for pre-Gen12 */
s/slpc/SLPC
Ok.
+ return guc->submission_supported &&
+ GRAPHICS_VER(guc_to_gt(guc)->i915) >= 12;
+}
+
+static bool __guc_slpc_selected(struct intel_guc *guc)
+{
+ if (!intel_guc_slpc_is_supported(guc))
+ return false;
+
+ return guc->submission_selected;
+}
+
+void intel_guc_slpc_init_early(struct intel_guc *guc)
+{
+ guc->slpc_supported = __guc_slpc_supported(guc);
+ guc->slpc_selected = __guc_slpc_selected(guc);
+}
in patch 4/16 you are introducing intel_guc_slpc.c|h so to have proper
encapsulation better to define this function as
void intel_guc_slpc_init_early(struct intel_guc_slpc *slpc) { }
and move it to intel_guc_slpc.c
done.
+
static inline struct intel_context *
g2h_context_lookup(struct intel_guc *guc, u32 desc_idx)
{
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
index be767eb6ff71..7ae5fd052faf 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
@@ -13,6 +13,7 @@
struct drm_printer;
struct intel_engine_cs;
+void intel_guc_slpc_init_early(struct intel_guc *guc);
it really does not belong to this .h
void intel_guc_submission_init_early(struct intel_guc *guc);
int intel_guc_submission_init(struct intel_guc *guc);
void intel_guc_submission_enable(struct intel_guc *guc);
@@ -50,4 +51,19 @@ static inline bool intel_guc_submission_is_used(struct
intel_guc *guc)
return intel_guc_is_used(guc) && intel_guc_submission_is_wanted(guc);
}
+static inline bool intel_guc_slpc_is_supported(struct intel_guc *guc)
+{
+ return guc->slpc_supported;
+}
+
+static inline bool intel_guc_slpc_is_wanted(struct intel_guc *guc)
+{
+ return guc->slpc_selected;
+}
+
+static inline bool intel_guc_slpc_is_used(struct intel_guc *guc)
+{
+ return intel_guc_submission_is_used(guc) &&
intel_guc_slpc_is_wanted(guc);
+}
did you try to define them in intel_guc_slpc.h ?
note that to avoid circular dependencies you can define slpc struct in
intel_guc_slpc_types.h and then
in intel_guc.h:
#include "intel_guc_slpc_types.h" instead of intel_guc_slpc.h
in intel_guc_slpc.h:
#include "intel_guc.h"
#include "intel_guc_slpc_types.h"
#include "intel_guc_submission.h"
that worked.
Thanks,
Vinay.
+
#endif
diff --git
[Intel-gfx] [PATCH 2/2] drm/i915/gem: Migrate to system at dma-buf attach time (v5)
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin() callback.
v4:
- Migrate in attach
v5: (jason)
- Lock around the migration
Signed-off-by: Thomas Hellström
Signed-off-by: Michael J. Ruhl
Reported-by: kernel test robot
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 25 ++-
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 4 ++-
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 9a655f69a0671..3163f00554476 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -170,8 +170,31 @@ static int i915_gem_dmabuf_attach(struct dma_buf *dmabuf,
struct dma_buf_attachment *attach)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf);
+ struct i915_gem_ww_ctx ww;
+ int err;
+
+ for_i915_gem_ww(&ww, err, true) {
+ err = i915_gem_object_lock(obj, &ww);
+ if (err)
+ continue;
+
+ if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM)) {
+ err = -EOPNOTSUPP;
+ continue;
+ }
+
+ err = i915_gem_object_migrate(obj, &ww, INTEL_REGION_SMEM);
+ if (err)
+ continue;
- return i915_gem_object_pin_pages_unlocked(obj);
+ err = i915_gem_object_wait_migration(obj, 0);
+ if (err)
+ continue;
+
+ err = i915_gem_object_pin_pages(obj);
+ }
+
+ return err;
}
static void i915_gem_dmabuf_detach(struct dma_buf *dmabuf,
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index 3dc0f8b3cdab0..4f7e77b1c0152 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -106,7 +106,9 @@ static int igt_dmabuf_import_same_driver(void *arg)
int err;
force_different_devices = true;
- obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
+ obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 0);
+ if (IS_ERR(obj))
+ obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
if (IS_ERR(obj))
goto out_ret;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf (v5)
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to recursive locking.
So taking the lock inside _pin_pages_unlocked() is incorrect.
Additionally, the current pinning code path is contrary to the defined
way that pinning should occur.
Remove the explicit pin/unpin from the map/umap functions and move them
to the attach/detach allowing correct locking to occur, and to match
the static dma-buf drm_prime pattern.
Add a live selftest to exercise both dynamic and non-dynamic
exports.
v2:
- Extend the selftest with a fake dynamic importer.
- Provide real pin and unpin callbacks to not abuse the interface.
v3: (ruhl)
- Remove the dynamic export support and move the pinning into the
attach/detach path.
v4: (ruhl)
- Put pages does not need to assert on the dma-resv
v5: (jason)
- Lock around dma_buf_unmap_attachment() when emulating a dynamic
importer in the subtests.
- Use pin_pages_unlocked
Reported-by: Michael J. Ruhl
Signed-off-by: Thomas Hellström
Signed-off-by: Michael J. Ruhl
Signed-off-by: Jason Ekstrand
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 43 +--
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 118 +-
2 files changed, 147 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 616c3a2f1baf0..9a655f69a0671 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -12,6 +12,8 @@
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
+I915_SELFTEST_DECLARE(static bool force_different_devices;)
+
static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
{
return to_intel_bo(buf->priv);
@@ -25,15 +27,11 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
struct scatterlist *src, *dst;
int ret, i;
- ret = i915_gem_object_pin_pages_unlocked(obj);
- if (ret)
- goto err;
-
/* Copy sg so that we make an independent mapping */
st = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
if (st == NULL) {
ret = -ENOMEM;
- goto err_unpin_pages;
+ goto err;
}
ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
@@ -58,8 +56,6 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
sg_free_table(st);
err_free:
kfree(st);
-err_unpin_pages:
- i915_gem_object_unpin_pages(obj);
err:
return ERR_PTR(ret);
}
@@ -68,13 +64,9 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment
*attachment,
struct sg_table *sg,
enum dma_data_direction dir)
{
- struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
-
dma_unmap_sgtable(attachment->dev, sg, dir, DMA_ATTR_SKIP_CPU_SYNC);
sg_free_table(sg);
kfree(sg);
-
- i915_gem_object_unpin_pages(obj);
}
static int i915_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map
*map)
@@ -168,7 +160,31 @@ static int i915_gem_end_cpu_access(struct dma_buf
*dma_buf, enum dma_data_direct
return err;
}
+/**
+ * i915_gem_dmabuf_attach - Do any extra attach work necessary
+ * @dmabuf: imported dma-buf
+ * @attach: new attach to do work on
+ *
+ */
+static int i915_gem_dmabuf_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf);
+
+ return i915_gem_object_pin_pages_unlocked(obj);
+}
+
+static void i915_gem_dmabuf_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf);
+
+ i915_gem_object_unpin_pages(obj);
+}
+
static const struct dma_buf_ops i915_dmabuf_ops = {
+ .attach = i915_gem_dmabuf_attach,
+ .detach = i915_gem_dmabuf_detach,
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
@@ -204,6 +220,8 @@ static int i915_gem_object_get_pages_dmabuf(struct
drm_i915_gem_object *obj)
struct sg_table *pages;
unsigned int sg_page_sizes;
+ assert_object_held(obj);
+
pages = dma_buf_map_attachment(obj->base.import_attach,
DMA_BIDIRECTIONAL);
if (IS_ERR(pages))
@@ -241,7 +259,8 @@ struct drm_gem_object *i915_gem_prime_import(struct
drm_device *dev,
if (dma_buf->ops == &i915_dmabuf_ops) {
obj = dma_buf_to_obj(dma_buf);
Re: [Intel-gfx] [PATCH 41/47] drm/i915/guc: Capture error state on context reset
On 6/24/2021 00:05, Matthew Brost wrote:
We receive notification of an engine reset from GuC at its
completion. Meaning GuC has potentially cleared any HW state
we may have been interested in capturing. GuC resumes scheduling
on the engine post-reset, as the resets are meant to be transparent,
further muddling our error state.
There is ongoing work to define an API for a GuC debug state dump. The
suggestion for now is to manually disable FW initiated resets in cases
where debug state is needed.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++
drivers/gpu/drm/i915/gt/intel_context.h | 3 ++
drivers/gpu/drm/i915/gt/intel_engine.h| 21 ++-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 11 --
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 35 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 25 ++---
7 files changed, 91 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 2f01437056a8..3fe7794b2bfd 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -514,6 +514,26 @@ struct i915_request *intel_context_create_request(struct
intel_context *ce)
return rq;
}
+struct i915_request *intel_context_find_active_request(struct intel_context *ce)
+{
+ struct i915_request *rq, *active = NULL;
+ unsigned long flags;
+
+ GEM_BUG_ON(!intel_engine_uses_guc(ce->engine));
+
+ spin_lock_irqsave(&ce->guc_active.lock, flags);
+ list_for_each_entry_reverse(rq, &ce->guc_active.requests,
+ sched.link) {
+ if (i915_request_completed(rq))
+ break;
+
+ active = rq;
+ }
+ spin_unlock_irqrestore(&ce->guc_active.lock, flags);
+
+ return active;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftest_context.c"
#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index a592a9605dc8..3363b59c0c40 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -201,6 +201,9 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
struct i915_request *intel_context_create_request(struct intel_context *ce);
+struct i915_request *
+intel_context_find_active_request(struct intel_context *ce);
+
static inline struct intel_ring *__intel_context_ring_size(u64 sz)
{
return u64_to_ptr(struct intel_ring, sz);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index e9e0657f847a..6ea5643a3aaa 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -245,7 +245,7 @@ ktime_t intel_engine_get_busy_time(struct intel_engine_cs
*engine,
ktime_t *now);
struct i915_request *
-intel_engine_find_active_request(struct intel_engine_cs *engine);
+intel_engine_execlist_find_hung_request(struct intel_engine_cs *engine);
u32 intel_engine_context_size(struct intel_gt *gt, u8 class);
struct intel_context *
@@ -328,4 +328,23 @@ intel_engine_get_sibling(struct intel_engine_cs *engine,
unsigned int sibling)
return engine->cops->get_sibling(engine, sibling);
}
+static inline void
+intel_engine_set_hung_context(struct intel_engine_cs *engine,
+ struct intel_context *ce)
+{
+ engine->hung_ce = ce;
+}
+
+static inline void
+intel_engine_clear_hung_context(struct intel_engine_cs *engine)
+{
+ intel_engine_set_hung_context(engine, NULL);
+}
+
+static inline struct intel_context *
+intel_engine_get_hung_context(struct intel_engine_cs *engine)
+{
+ return engine->hung_ce;
+}
+
#endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 69245670b8b0..1d243b83b023 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1671,7 +1671,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
drm_printf(m, "\tRequests:\n");
spin_lock_irqsave(&engine->sched_engine->lock, flags);
- rq = intel_engine_find_active_request(engine);
+ rq = intel_engine_execlist_find_hung_request(engine);
if (rq) {
struct intel_timeline *tl = get_timeline(rq);
@@ -1782,10 +1782,17 @@ static bool match_ring(struct i915_request *rq)
}
struct i915_request *
-intel_engine_find_active_request(struct intel_engine_cs *engine)
+intel_engine_execlist_find_hung_request(struct intel_engine_cs *engine)
{
struct i915_request *request, *active = NULL;
+ /*
+* This search does not work in GuC submission mode.
Re: [Intel-gfx] [PATCH v2 05/12] drm/i915/bxt: Use revid->stepping tables
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 05/12] drm/i915/bxt: Use revid->stepping tables
>
> Switch BXT to use a revid->stepping table as we're trying to do on all
> platforms going forward. Note that the REVID macros we had before
> weren't being used anywhere in the code and weren't even correct; the
> table values come from the bspec (and omits all the placeholder and
> preproduction revisions).
>
> Although nothing in the code is using the data from this table at the moment,
> we expect some upcoming DMC patches to start utilizing it.
>
> Bspec: 13620
> Cc: Anusha Srivatsa
> Signed-off-by: Matt Roper
Thanks for the patch,
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_drv.h | 9 -
> drivers/gpu/drm/i915/intel_step.c | 10 ++
> 2 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index f30499ed6787..afb159f2a658
> 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1517,15 +1517,6 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
>
> #define IS_SKL_GT_STEP(p, since, until) (IS_SKYLAKE(p) && IS_GT_STEP(p,
> since, until))
>
> -#define BXT_REVID_A0 0x0
> -#define BXT_REVID_A1 0x1
> -#define BXT_REVID_B0 0x3
> -#define BXT_REVID_B_LAST 0x8
> -#define BXT_REVID_C0 0x9
> -
> -#define IS_BXT_REVID(dev_priv, since, until) \
> - (IS_BROXTON(dev_priv) && IS_REVID(dev_priv, since, until))
> -
> #define IS_KBL_GT_STEP(dev_priv, since, until) \
> (IS_KABYLAKE(dev_priv) && IS_GT_STEP(dev_priv, since, until))
> #define IS_KBL_DISPLAY_STEP(dev_priv, since, until) \ diff --git
> a/drivers/gpu/drm/i915/intel_step.c b/drivers/gpu/drm/i915/intel_step.c
> index 8987453aa172..41e3904ae6e8 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -42,6 +42,13 @@ static const struct intel_step_info kbl_revids[] = {
> [7] = { .gt_step = STEP_G0, .display_step = STEP_C0 }, };
>
> +static const struct intel_step_info bxt_revids[] = {
> + [0xA] = { COMMON_STEPPING(C0) },
> + [0xB] = { COMMON_STEPPING(C0) },
> + [0xC] = { COMMON_STEPPING(D0) },
> + [0xD] = { COMMON_STEPPING(E0) },
> +};
> +
> static const struct intel_step_info tgl_uy_revids[] = {
> [0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
> [1] = { .gt_step = STEP_B0, .display_step = STEP_C0 }, @@ -89,6 +96,9
> @@ void intel_step_init(struct drm_i915_private *i915)
> } else if (IS_TIGERLAKE(i915)) {
> revids = tgl_revids;
> size = ARRAY_SIZE(tgl_revids);
> + } else if (IS_BROXTON(i915)) {
> + revids = bxt_revids;
> + size = ARRAY_SIZE(bxt_revids);
> } else if (IS_KABYLAKE(i915)) {
> revids = kbl_revids;
> size = ARRAY_SIZE(kbl_revids);
> --
> 2.25.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/12] drm/i915/skl: Use revid->stepping tables
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 03/12] drm/i915/skl: Use revid->stepping tables
>
> Switch SKL to use a revid->stepping table as we're trying to do on all
> platforms going forward. Also drop the preproduction revisions and add the
> newer steppings we hadn't already handled.
>
> Note that SKL has a case where a newer revision ID corresponds to an older
> GT/disp stepping (0x9 -> STEP_J0, 0xA -> STEP_I1). Also, the lack of a
> revision
> ID 0x8 in the table is intentional and not an oversight.
> We'll re-write the KBL-specific comment to make it clear that these kind of
> quirks are expected.
>
> v2:
> - Since GT and display steppings are always identical on SKL use a
>macro to set both values at once in a more readable manner. (Anusha)
> - Drop preproduction steppings.
>
> Bspec: 13626
> Cc: Anusha Srivatsa
> Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 11 +---
> drivers/gpu/drm/i915/intel_step.c | 30 +
> drivers/gpu/drm/i915/intel_step.h | 4 +++
> 4 files changed, 31 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index d9a5a445ceec..6dfd564e078f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -883,7 +883,7 @@ skl_gt_workarounds_init(struct drm_i915_private
> *i915, struct i915_wa_list *wal)
> GEN8_EU_GAUNIT_CLOCK_GATE_DISABLE);
>
> /* WaInPlaceDecompressionHang:skl */
> - if (IS_SKL_REVID(i915, SKL_REVID_H0, REVID_FOREVER))
> + if (IS_SKL_GT_STEP(i915, STEP_H0, STEP_FOREVER))
> wa_write_or(wal,
> GEN9_GAMT_ECO_REG_RW_IA,
> GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index c4747f4407ef..f30499ed6787
> 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1515,16 +1515,7 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915, #define IS_TGL_Y(dev_priv) \
> IS_SUBPLATFORM(dev_priv, INTEL_TIGERLAKE,
> INTEL_SUBPLATFORM_ULX)
>
> -#define SKL_REVID_A0 0x0
> -#define SKL_REVID_B0 0x1
> -#define SKL_REVID_C0 0x2
> -#define SKL_REVID_D0 0x3
> -#define SKL_REVID_E0 0x4
> -#define SKL_REVID_F0 0x5
> -#define SKL_REVID_G0 0x6
> -#define SKL_REVID_H0 0x7
> -
> -#define IS_SKL_REVID(p, since, until) (IS_SKYLAKE(p) && IS_REVID(p, since,
> until))
> +#define IS_SKL_GT_STEP(p, since, until) (IS_SKYLAKE(p) && IS_GT_STEP(p,
> +since, until))
>
> #define BXT_REVID_A0 0x0
> #define BXT_REVID_A1 0x1
> diff --git a/drivers/gpu/drm/i915/intel_step.c
> b/drivers/gpu/drm/i915/intel_step.c
> index 93ccd42f2514..69c928b046e8 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -7,14 +7,31 @@
> #include "intel_step.h"
>
> /*
> - * KBL revision ID ordering is bizarre; higher revision ID's map to lower
> - * steppings in some cases. So rather than test against the revision ID
> - * directly, let's map that into our own range of increasing ID's that we
> - * can test against in a regular manner.
> + * Some platforms have unusual ways of mapping PCI revision ID to
> + GT/display
> + * steppings. E.g., in some cases a higher PCI revision may translate
> + to a
> + * lower stepping of the GT and/or display IP. This file provides
> + lookup
> + * tables to map the PCI revision into a standard set of stepping
> + values that
> + * can be compared numerically.
> + *
> + * Also note that some revisions/steppings may have been set aside as
> + * placeholders but never materialized in real hardware; in those cases
> + there
> + * may be jumps in the revision IDs or stepping values in the tables below.
> */
>
> +/*
> + * Some platforms always have the same stepping value for GT and
> +display;
> + * use a macro to define these to make it easier to identify the
> +platforms
> + * where the two steppings can deviate.
> + */
> +#define COMMON_STEPPING(x) .gt_step = STEP_##x, .display_step =
> +STEP_##x
> +
> +static const struct intel_step_info skl_revids[] = {
> + [0x6] = { COMMON_STEPPING(G0) },
> + [0x7] = { COMMON_STEPPING(H0) },
> + [0x9] = { COMMON_STEPPING(J0) },
> + [0xA] = { COMMON_STEPPING(I1) },
> +};
>
> -/* FIXME: what about REVID_E0 */
> static const struct intel_step_info kbl_revids[] = {
> [0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
> [1] = { .gt_step = STEP_B0, .display_step = STEP_B0 }, @@ -76,6 +93,9
> @@ void intel_step_init(st
Re: [Intel-gfx] [PATCH 37/47] drm/i915/guc: Enable the timer expired interrupt for GuC
On 6/24/2021 00:05, Matthew Brost wrote: The GuC can implement execution qunatums, detect hung contexts and other such things but it requires the timer expired interrupt to do so. Signed-off-by: Matthew Brost CC: John Harrison Reviewed-by: John Harrison --- drivers/gpu/drm/i915/gt/intel_rps.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c index 06e9a8ed4e03..0c8e7f2b06f0 100644 --- a/drivers/gpu/drm/i915/gt/intel_rps.c +++ b/drivers/gpu/drm/i915/gt/intel_rps.c @@ -1877,6 +1877,10 @@ void intel_rps_init(struct intel_rps *rps) if (GRAPHICS_VER(i915) >= 8 && GRAPHICS_VER(i915) < 11) rps->pm_intrmsk_mbz |= GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC; + + /* GuC needs ARAT expired interrupt unmasked */ + if (intel_uc_uses_guc_submission(&rps_to_gt(rps)->uc)) + rps->pm_intrmsk_mbz |= ARAT_EXPIRED_INTRMSK; } void intel_rps_sanitize(struct intel_rps *rps) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 36/47] drm/i915/guc: Handle engine reset failure notification
On 6/24/2021 00:05, Matthew Brost wrote:
GuC will notify the driver, via G2H, if it fails to
reset an engine. We recover by resorting to a full GPU
reset.
Signed-off-by: Matthew Brost
Signed-off-by: Fernando Pacheco
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 3 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 43 +++
3 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index e94b0ef733da..99742625e6ff 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -264,6 +264,8 @@ int intel_guc_sched_done_process_msg(struct intel_guc *guc,
const u32 *msg, u32 len);
int intel_guc_context_reset_process_msg(struct intel_guc *guc,
const u32 *msg, u32 len);
+int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
+const u32 *msg, u32 len);
void intel_guc_submission_reset_prepare(struct intel_guc *guc);
void intel_guc_submission_reset(struct intel_guc *guc, bool stalled);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index a2020373b8e8..dd6177c8d75c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -948,6 +948,9 @@ static int ct_process_request(struct intel_guc_ct *ct,
struct ct_incoming_msg *r
case INTEL_GUC_ACTION_CONTEXT_RESET_NOTIFICATION:
ret = intel_guc_context_reset_process_msg(guc, payload, len);
break;
+ case INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION:
+ ret = intel_guc_engine_failure_process_msg(guc, payload, len);
+ break;
default:
ret = -EOPNOTSUPP;
break;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9845c5bd9832..c3223958dfe0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2227,6 +2227,49 @@ int intel_guc_context_reset_process_msg(struct intel_guc
*guc,
return 0;
}
+static struct intel_engine_cs *
+guc_lookup_engine(struct intel_guc *guc, u8 guc_class, u8 instance)
+{
+ struct intel_gt *gt = guc_to_gt(guc);
+ u8 engine_class = guc_class_to_engine_class(guc_class);
+
+ /* Class index is checked in class converter */
+ GEM_BUG_ON(instance > MAX_ENGINE_INSTANCE);
+
+ return gt->engine_class[engine_class][instance];
+}
+
+int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
+const u32 *msg, u32 len)
+{
+ struct intel_engine_cs *engine;
+ u8 guc_class, instance;
+ u32 reason;
+
+ if (unlikely(len != 3)) {
+ drm_dbg(&guc_to_gt(guc)->i915->drm, "Invalid length %u", len);
+ return -EPROTO;
+ }
+
+ guc_class = msg[0];
+ instance = msg[1];
+ reason = msg[2];
+
+ engine = guc_lookup_engine(guc, guc_class, instance);
+ if (unlikely(!engine)) {
+ drm_dbg(&guc_to_gt(guc)->i915->drm,
+ "Invalid engine %d:%d", guc_class, instance);
+ return -EPROTO;
+ }
+
+ intel_gt_handle_error(guc_to_gt(guc), engine->mask,
+ I915_ERROR_CAPTURE,
+ "GuC failed to reset %s (reason=0x%08x)\n",
+ engine->name, reason);
+
+ return 0;
+}
+
void intel_guc_log_submission_info(struct intel_guc *guc,
struct drm_printer *p)
{
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 35/47] drm/i915/guc: Handle context reset notification
On 6/24/2021 00:05, Matthew Brost wrote:
GuC will issue a reset on detecting an engine hang and will notify
the driver via a G2H message. The driver will service the notification
by resetting the guilty context to a simple state or banning it
completely.
Cc: Matthew Brost
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 3 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 35 +++
drivers/gpu/drm/i915/i915_trace.h | 10 ++
4 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 85ef6767f13b..e94b0ef733da 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -262,6 +262,8 @@ int intel_guc_deregister_done_process_msg(struct intel_guc
*guc,
const u32 *msg, u32 len);
int intel_guc_sched_done_process_msg(struct intel_guc *guc,
const u32 *msg, u32 len);
+int intel_guc_context_reset_process_msg(struct intel_guc *guc,
+ const u32 *msg, u32 len);
void intel_guc_submission_reset_prepare(struct intel_guc *guc);
void intel_guc_submission_reset(struct intel_guc *guc, bool stalled);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 4ed074df88e5..a2020373b8e8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -945,6 +945,9 @@ static int ct_process_request(struct intel_guc_ct *ct,
struct ct_incoming_msg *r
case INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE:
ret = intel_guc_sched_done_process_msg(guc, payload, len);
break;
+ case INTEL_GUC_ACTION_CONTEXT_RESET_NOTIFICATION:
+ ret = intel_guc_context_reset_process_msg(guc, payload, len);
+ break;
default:
ret = -EOPNOTSUPP;
break;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 16b61fe71b07..9845c5bd9832 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2192,6 +2192,41 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
return 0;
}
+static void guc_context_replay(struct intel_context *ce)
+{
+ struct i915_sched_engine *sched_engine = ce->engine->sched_engine;
+
+ __guc_reset_context(ce, true);
+ tasklet_hi_schedule(&sched_engine->tasklet);
+}
+
+static void guc_handle_context_reset(struct intel_guc *guc,
+struct intel_context *ce)
+{
+ trace_intel_context_reset(ce);
+ guc_context_replay(ce);
+}
+
+int intel_guc_context_reset_process_msg(struct intel_guc *guc,
+ const u32 *msg, u32 len)
+{
+ struct intel_context *ce;
+ int desc_idx = msg[0];
Should do this dereference after checking the length? Or is it
guaranteed that the length cannot be zero?
John.
+
+ if (unlikely(len != 1)) {
+ drm_dbg(&guc_to_gt(guc)->i915->drm, "Invalid length %u", len);
+ return -EPROTO;
+ }
+
+ ce = g2h_context_lookup(guc, desc_idx);
+ if (unlikely(!ce))
+ return -EPROTO;
+
+ guc_handle_context_reset(guc, ce);
+
+ return 0;
+}
+
void intel_guc_log_submission_info(struct intel_guc *guc,
struct drm_printer *p)
{
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 97c2e83984ed..c095c4d39456 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -929,6 +929,11 @@ DECLARE_EVENT_CLASS(intel_context,
__entry->guc_sched_state_no_lock)
);
+DEFINE_EVENT(intel_context, intel_context_reset,
+TP_PROTO(struct intel_context *ce),
+TP_ARGS(ce)
+);
+
DEFINE_EVENT(intel_context, intel_context_register,
TP_PROTO(struct intel_context *ce),
TP_ARGS(ce)
@@ -1026,6 +1031,11 @@ trace_i915_request_out(struct i915_request *rq)
{
}
+static inline void
+trace_intel_context_reset(struct intel_context *ce)
+{
+}
+
static inline void
trace_intel_context_register(struct intel_context *ce)
{
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 34/47] drm/i915/guc: Suspend/resume implementation for new interface
On 6/24/2021 00:05, Matthew Brost wrote:
The new GuC interface introduces an MMIO H2G command,
INTEL_GUC_ACTION_RESET_CLIENT, which is used to implement suspend. This
MMIO tears down any active contexts generating a context reset G2H CTB
for each. Once that step completes the GuC tears down the CTB
channels. It is safe to suspend once this MMIO H2G command completes
and all G2H CTBs have been processed. In practice the i915 will likely
never receive a G2H as suspend should only be called after the GPU is
idle.
Resume is implemented in the same manner as before - simply reload the
GuC firmware and reinitialize everything (e.g. CTB channels, contexts,
etc..).
Cc: John Harrison
Signed-off-by: Matthew Brost
Signed-off-by: Michal Wajdeczko
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 64 ---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 14 ++--
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 5 ++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 20 --
5 files changed, 53 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 57e18babdf4b..596cf4b818e5 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -142,6 +142,7 @@ enum intel_guc_action {
INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER = 0x4506,
INTEL_GUC_ACTION_DEREGISTER_CONTEXT_DONE = 0x4600,
+ INTEL_GUC_ACTION_RESET_CLIENT = 0x5B01,
INTEL_GUC_ACTION_LIMIT
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 9b09395b998f..68266cbffd1f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -524,51 +524,34 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32
rsa_offset)
*/
int intel_guc_suspend(struct intel_guc *guc)
{
- struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
int ret;
- u32 status;
u32 action[] = {
- INTEL_GUC_ACTION_ENTER_S_STATE,
- GUC_POWER_D1, /* any value greater than GUC_POWER_D0 */
+ INTEL_GUC_ACTION_RESET_CLIENT,
};
- /*
-* If GuC communication is enabled but submission is not supported,
-* we do not need to suspend the GuC.
-*/
- if (!intel_guc_submission_is_used(guc) || !intel_guc_is_ready(guc))
+ if (!intel_guc_is_ready(guc))
return 0;
- /*
-* The ENTER_S_STATE action queues the save/restore operation in GuC FW
-* and then returns, so waiting on the H2G is not enough to guarantee
-* GuC is done. When all the processing is done, GuC writes
-* INTEL_GUC_SLEEP_STATE_SUCCESS to scratch register 14, so we can poll
-* on that. Note that GuC does not ensure that the value in the register
-* is different from INTEL_GUC_SLEEP_STATE_SUCCESS while the action is
-* in progress so we need to take care of that ourselves as well.
-*/
-
- intel_uncore_write(uncore, SOFT_SCRATCH(14),
- INTEL_GUC_SLEEP_STATE_INVALID_MASK);
-
- ret = intel_guc_send(guc, action, ARRAY_SIZE(action));
- if (ret)
- return ret;
-
- ret = __intel_wait_for_register(uncore, SOFT_SCRATCH(14),
- INTEL_GUC_SLEEP_STATE_INVALID_MASK,
- 0, 0, 10, &status);
- if (ret)
- return ret;
-
- if (status != INTEL_GUC_SLEEP_STATE_SUCCESS) {
- DRM_ERROR("GuC failed to change sleep state. "
- "action=0x%x, err=%u\n",
- action[0], status);
- return -EIO;
+ if (intel_guc_submission_is_used(guc)) {
+ /*
+* This H2G MMIO command tears down the GuC in two steps. First
it will
+* generate a G2H CTB for every active context indicating a
reset. In
+* practice the i915 shouldn't ever get a G2H as suspend should
only be
+* called when the GPU is idle. Next, it tears down the CTBs
and this
+* H2G MMIO command completes.
+*
+* Don't abort on a failure code from the GuC. Keep going and
do the
+* clean up in santize() and re-initialisation on resume and
hopefully
+* the error here won't be problematic.
+*/
+ ret = intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
NULL, 0);
+ if (ret)
+ DRM_ERROR("GuC suspend: RESET_CLIENT action failed with
error %d!\n", ret);
}
+ /* Signal that the GuC isn't running. */
+ intel_guc_sanit
Re: [Intel-gfx] [PATCH v2 09/12] drm/i915/rkl: Use revid->stepping tables
On Mon, Jul 12, 2021 at 03:51:15PM -0700, Srivatsa, Anusha wrote:
>
>
> > -Original Message-
> > From: Roper, Matthew D
> > Sent: Friday, July 9, 2021 8:37 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Srivatsa, Anusha ; Roper, Matthew D
> >
> > Subject: [PATCH v2 09/12] drm/i915/rkl: Use revid->stepping tables
> >
> > Switch RKL to use a revid->stepping table as we're trying to do on all
> > platforms going forward.
> >
> > Bspec: 44501
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 4 ++--
> > drivers/gpu/drm/i915/i915_drv.h | 8 ++--
> > drivers/gpu/drm/i915/intel_step.c| 9 +
> > 3 files changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 9643624fe160..74b2aa3c2946 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -594,7 +594,7 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> > if (intel_dp->psr.psr2_sel_fetch_enabled) {
> > /* WA 1408330847 */
> > if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
> > - IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
> > + IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0))
> > intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
> > DIS_RAM_BYPASS_PSR2_MAN_TRACK,
> > DIS_RAM_BYPASS_PSR2_MAN_TRACK);
> > @@ -1342,7 +1342,7 @@ static void intel_psr_disable_locked(struct intel_dp
> > *intel_dp)
> > /* WA 1408330847 */
> > if (intel_dp->psr.psr2_sel_fetch_enabled &&
> > (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
> > -IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
> > +IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0)))
> > intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
> > DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index b3ce2b73a143..9195131cf90f
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1549,12 +1549,8 @@ IS_SUBPLATFORM(const struct drm_i915_private
> > *i915,
> > (IS_TIGERLAKE(__i915) && !(IS_TGL_U(__i915) || IS_TGL_Y(__i915))
> > && \
> > IS_GT_STEP(__i915, since, until))
> >
> > -#define RKL_REVID_A0 0x0
> > -#define RKL_REVID_B0 0x1
> > -#define RKL_REVID_C0 0x4
> > -
> > -#define IS_RKL_REVID(p, since, until) \
> > - (IS_ROCKETLAKE(p) && IS_REVID(p, since, until))
> > +#define IS_RKL_DISPLAY_STEP(p, since, until) \
> > + (IS_ROCKETLAKE(p) && IS_DISPLAY_STEP(p, since, until))
> >
>
> If a platform has the same gt and display stepping, I wonder if we
> should stick to using IS__GT_STEP while replacing
> IS_REVID instances. The previous patches have
> IS__GT_STEP.
> Just a thought.
No, we want to be very explicit about which IP block the stepping
belongs to to avoid mistakes. Just because the steppings are equivalent
right now doesn't mean a new revision won't show up in the future that
has different GT vs display steppings. In that case it's easy to update
the table, but we don't want to have to dig through the rest of the code
looking for places where we used the wrong macro. Plus, intentionally
using the wrong macro on a platform where it doesn't matter is going to
lead to copy/paste errors when people add additional platforms to a
workaround.
Matt
>
> Anusha
>
> > #define DG1_REVID_A0 0x0
> > #define DG1_REVID_B0 0x1
> > diff --git a/drivers/gpu/drm/i915/intel_step.c
> > b/drivers/gpu/drm/i915/intel_step.c
> > index 6e1b132ecf38..21211649e6bb 100644
> > --- a/drivers/gpu/drm/i915/intel_step.c
> > +++ b/drivers/gpu/drm/i915/intel_step.c
> > @@ -75,6 +75,12 @@ static const struct intel_step_info tgl_revids[] = {
> > [1] = { .gt_step = STEP_B0, .display_step = STEP_D0 }, };
> >
> > +static const struct intel_step_info rkl_revids[] = {
> > + [0] = { COMMON_STEPPING(A0) },
> > + [1] = { COMMON_STEPPING(B0) },
> > + [4] = { COMMON_STEPPING(C0) },
> > +};
> > +
> > static const struct intel_step_info adls_revids[] = {
> > [0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
> > [0x1] = { .gt_step = STEP_A0, .display_step = STEP_A2 }, @@ -103,6
> > +109,9 @@ void intel_step_init(struct drm_i915_private *i915)
> > } else if (IS_ALDERLAKE_S(i915)) {
> > revids = adls_revids;
> > size = ARRAY_SIZE(adls_revids);
> > + } else if (IS_ROCKETLAKE(i915)) {
> > + revids = rkl_revids;
> > + size = ARRAY_SIZE(rkl_revids);
> > } else if (IS_TGL_U(i915) || IS_TGL_Y(i915)) {
> > revids = tgl_uy_revids;
> > size = ARRAY_SIZE(tgl_uy_revids);
> > --
> > 2.25.4
>
--
Mat
Re: [Intel-gfx] [PATCH v2 11/12] drm/i915/cnl: Drop all workarounds
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 11/12] drm/i915/cnl: Drop all workarounds
>
> All of the Cannon Lake hardware that came out had graphics fused off, and
> our userspace drivers have already dropped their support for the platform;
> CNL-specific code in i915 that isn't inherited by subsequent platforms is
> effectively dead code. Let's remove all of the CNL-specific workarounds as a
> quick and easy first step.
>
> References: https://gitlab.freedesktop.org/mesa/mesa/-
> /merge_requests/6899
> Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 55 -
> drivers/gpu/drm/i915/i915_drv.h | 7 ---
> 2 files changed, 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 62321e9149db..9b257a394305 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -514,35 +514,6 @@ static void cfl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
>
> GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE);
> }
>
> -static void cnl_ctx_workarounds_init(struct intel_engine_cs *engine,
> - struct i915_wa_list *wal)
> -{
> - /* WaForceContextSaveRestoreNonCoherent:cnl */
> - wa_masked_en(wal, CNL_HDC_CHICKEN0,
> -
> HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT);
> -
> - /* WaDisableReplayBufferBankArbitrationOptimization:cnl */
> - wa_masked_en(wal, COMMON_SLICE_CHICKEN2,
> - GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
> -
> - /* WaPushConstantDereferenceHoldDisable:cnl */
> - wa_masked_en(wal, GEN7_ROW_CHICKEN2,
> PUSH_CONSTANT_DEREF_DISABLE);
> -
> - /* FtrEnableFastAnisoL1BankingFix:cnl */
> - wa_masked_en(wal, HALF_SLICE_CHICKEN3,
> CNL_FAST_ANISO_L1_BANKING_FIX);
> -
> - /* WaDisable3DMidCmdPreemption:cnl */
> - wa_masked_dis(wal, GEN8_CS_CHICKEN1,
> GEN9_PREEMPT_3D_OBJECT_LEVEL);
> -
> - /* WaDisableGPGPUMidCmdPreemption:cnl */
> - wa_masked_field_set(wal, GEN8_CS_CHICKEN1,
> - GEN9_PREEMPT_GPGPU_LEVEL_MASK,
> - GEN9_PREEMPT_GPGPU_COMMAND_LEVEL);
> -
> - /* WaDisableEarlyEOT:cnl */
> - wa_masked_en(wal, GEN8_ROW_CHICKEN, DISABLE_EARLY_EOT);
> -}
> -
> static void icl_ctx_workarounds_init(struct intel_engine_cs *engine,
>struct i915_wa_list *wal)
> {
> @@ -704,8 +675,6 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs
> *engine,
> gen12_ctx_workarounds_init(engine, wal);
> else if (GRAPHICS_VER(i915) == 11)
> icl_ctx_workarounds_init(engine, wal);
> - else if (IS_CANNONLAKE(i915))
> - cnl_ctx_workarounds_init(engine, wal);
> else if (IS_COFFEELAKE(i915) || IS_COMETLAKE(i915))
> cfl_ctx_workarounds_init(engine, wal);
> else if (IS_GEMINILAKE(i915))
> @@ -982,15 +951,6 @@ icl_wa_init_mcr(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> wa_write_clr_set(wal, GEN8_MCR_SELECTOR, mcr_mask, mcr); }
>
> -static void
> -cnl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal) -{
> - /* WaInPlaceDecompressionHang:cnl */
> - wa_write_or(wal,
> - GEN9_GAMT_ECO_REG_RW_IA,
> - GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
> -}
> -
> static void
> icl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal) { @@ -1140,8 +1100,6 @@ gt_init_workarounds(struct
> drm_i915_private *i915, struct i915_wa_list *wal)
> gen12_gt_workarounds_init(i915, wal);
> else if (GRAPHICS_VER(i915) == 11)
> icl_gt_workarounds_init(i915, wal);
> - else if (IS_CANNONLAKE(i915))
> - cnl_gt_workarounds_init(i915, wal);
> else if (IS_COFFEELAKE(i915) || IS_COMETLAKE(i915))
> cfl_gt_workarounds_init(i915, wal);
> else if (IS_GEMINILAKE(i915))
> @@ -1418,17 +1376,6 @@ static void cml_whitelist_build(struct
> intel_engine_cs *engine)
> cfl_whitelist_build(engine);
> }
>
> -static void cnl_whitelist_build(struct intel_engine_cs *engine) -{
> - struct i915_wa_list *w = &engine->whitelist;
> -
> - if (engine->class != RENDER_CLASS)
> - return;
> -
> - /* WaEnablePreemptionGranularityControlByUMD:cnl */
> - whitelist_reg(w, GEN8_CS_CHICKEN1);
> -}
> -
> static void icl_whitelist_build(struct intel_engine_cs *engine) {
> struct i915_wa_list *w = &engine->whitelist; @@ -1542,8 +1489,6
> @@ void intel_engine_init_whitelist(struct intel_engine_cs *engine)
> tgl_whitelist_build(engine);
> else if (GRAPHICS_VER(i915) == 11)
> icl_whitelist_build(engine);
> - els
Re: [Intel-gfx] [PATCH v2 09/12] drm/i915/rkl: Use revid->stepping tables
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 09/12] drm/i915/rkl: Use revid->stepping tables
>
> Switch RKL to use a revid->stepping table as we're trying to do on all
> platforms going forward.
>
> Bspec: 44501
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 4 ++--
> drivers/gpu/drm/i915/i915_drv.h | 8 ++--
> drivers/gpu/drm/i915/intel_step.c| 9 +
> 3 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 9643624fe160..74b2aa3c2946 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -594,7 +594,7 @@ static void hsw_activate_psr2(struct intel_dp
> *intel_dp)
> if (intel_dp->psr.psr2_sel_fetch_enabled) {
> /* WA 1408330847 */
> if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
> - IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
> + IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0))
> intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>DIS_RAM_BYPASS_PSR2_MAN_TRACK,
>DIS_RAM_BYPASS_PSR2_MAN_TRACK);
> @@ -1342,7 +1342,7 @@ static void intel_psr_disable_locked(struct intel_dp
> *intel_dp)
> /* WA 1408330847 */
> if (intel_dp->psr.psr2_sel_fetch_enabled &&
> (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
> - IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
> + IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0)))
> intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
>DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index b3ce2b73a143..9195131cf90f
> 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1549,12 +1549,8 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
> (IS_TIGERLAKE(__i915) && !(IS_TGL_U(__i915) || IS_TGL_Y(__i915))
> && \
>IS_GT_STEP(__i915, since, until))
>
> -#define RKL_REVID_A0 0x0
> -#define RKL_REVID_B0 0x1
> -#define RKL_REVID_C0 0x4
> -
> -#define IS_RKL_REVID(p, since, until) \
> - (IS_ROCKETLAKE(p) && IS_REVID(p, since, until))
> +#define IS_RKL_DISPLAY_STEP(p, since, until) \
> + (IS_ROCKETLAKE(p) && IS_DISPLAY_STEP(p, since, until))
>
If a platform has the same gt and display stepping, I wonder if we should stick
to using IS__GT_STEP while replacing IS_REVID instances.
The previous patches have IS__GT_STEP.
Just a thought.
Anusha
> #define DG1_REVID_A0 0x0
> #define DG1_REVID_B0 0x1
> diff --git a/drivers/gpu/drm/i915/intel_step.c
> b/drivers/gpu/drm/i915/intel_step.c
> index 6e1b132ecf38..21211649e6bb 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -75,6 +75,12 @@ static const struct intel_step_info tgl_revids[] = {
> [1] = { .gt_step = STEP_B0, .display_step = STEP_D0 }, };
>
> +static const struct intel_step_info rkl_revids[] = {
> + [0] = { COMMON_STEPPING(A0) },
> + [1] = { COMMON_STEPPING(B0) },
> + [4] = { COMMON_STEPPING(C0) },
> +};
> +
> static const struct intel_step_info adls_revids[] = {
> [0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
> [0x1] = { .gt_step = STEP_A0, .display_step = STEP_A2 }, @@ -103,6
> +109,9 @@ void intel_step_init(struct drm_i915_private *i915)
> } else if (IS_ALDERLAKE_S(i915)) {
> revids = adls_revids;
> size = ARRAY_SIZE(adls_revids);
> + } else if (IS_ROCKETLAKE(i915)) {
> + revids = rkl_revids;
> + size = ARRAY_SIZE(rkl_revids);
> } else if (IS_TGL_U(i915) || IS_TGL_Y(i915)) {
> revids = tgl_uy_revids;
> size = ARRAY_SIZE(tgl_uy_revids);
> --
> 2.25.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/12] drm/i915/jsl_ehl: Use revid->stepping tables
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 08/12] drm/i915/jsl_ehl: Use revid->stepping tables
>
> Switch JSL/EHL to use a revid->stepping table as we're trying to do on all
> platforms going forward.
>
> Bspec: 29153
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 9 -
> drivers/gpu/drm/i915/intel_step.c | 8
> 4 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 882bfd499e55..dfc31b682848 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -2674,7 +2674,7 @@ static bool
> ehl_combo_pll_div_frac_wa_needed(struct drm_i915_private *i915) {
> return ((IS_PLATFORM(i915, INTEL_ELKHARTLAKE) &&
> - IS_JSL_EHL_REVID(i915, EHL_REVID_B0, REVID_FOREVER))
> ||
> + IS_JSL_EHL_DISPLAY_STEP(i915, STEP_B0, STEP_FOREVER))
> ||
>IS_TIGERLAKE(i915) || IS_ALDERLAKE_P(i915)) &&
>i915->dpll.ref_clks.nssc == 38400;
> }
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index e2d8acb8c1c9..4c0c15bbdac2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1043,7 +1043,7 @@ icl_gt_workarounds_init(struct drm_i915_private
> *i915, struct i915_wa_list *wal)
>
> /* Wa_1607087056:icl,ehl,jsl */
> if (IS_ICELAKE(i915) ||
> - IS_JSL_EHL_REVID(i915, EHL_REVID_A0, EHL_REVID_A0))
> + IS_JSL_EHL_GT_STEP(i915, STEP_A0, STEP_A0))
> wa_write_or(wal,
> SLICE_UNIT_LEVEL_CLKGATE,
> L3_CLKGATE_DIS | L3_CR2X_CLKGATE_DIS); diff --
> git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d4f705f06c73..b3ce2b73a143 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1532,11 +1532,10 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915, #define IS_ICL_GT_STEP(p, since, until) \
> (IS_ICELAKE(p) && IS_GT_STEP(p, since, until))
>
> -#define EHL_REVID_A00x0
> -#define EHL_REVID_B00x1
> -
> -#define IS_JSL_EHL_REVID(p, since, until) \
> - (IS_JSL_EHL(p) && IS_REVID(p, since, until))
> +#define IS_JSL_EHL_GT_STEP(p, since, until) \
> + (IS_JSL_EHL(p) && IS_GT_STEP(p, since, until)) #define
> +IS_JSL_EHL_DISPLAY_STEP(p, since, until) \
> + (IS_JSL_EHL(p) && IS_DISPLAY_STEP(p, since, until))
>
> #define IS_TGL_DISPLAY_STEP(__i915, since, until) \
> (IS_TIGERLAKE(__i915) && \
> diff --git a/drivers/gpu/drm/i915/intel_step.c
> b/drivers/gpu/drm/i915/intel_step.c
> index f8be464d1179..6e1b132ecf38 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -57,6 +57,11 @@ static const struct intel_step_info icl_revids[] = {
> [7] = { COMMON_STEPPING(D0) },
> };
>
> +static const struct intel_step_info jsl_ehl_revids[] = {
> + [0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
> + [1] = { .gt_step = STEP_B0, .display_step = STEP_B0 }, };
> +
Here COMMON_STEEPING can be used.
Anusha
> static const struct intel_step_info tgl_uy_revids[] = {
> [0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
> [1] = { .gt_step = STEP_B0, .display_step = STEP_C0 }, @@ -104,6
> +109,9 @@ void intel_step_init(struct drm_i915_private *i915)
> } else if (IS_TIGERLAKE(i915)) {
> revids = tgl_revids;
> size = ARRAY_SIZE(tgl_revids);
> + } else if (IS_JSL_EHL(i915)) {
> + revids = jsl_ehl_revids;
> + size = ARRAY_SIZE(jsl_ehl_revids);
> } else if (IS_ICELAKE(i915)) {
> revids = icl_revids;
> size = ARRAY_SIZE(icl_revids);
> --
> 2.25.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/47] drm/i915: Add intel_context tracing
On 7/12/2021 14:47, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:10:40AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Add intel_context tracing. These trace points are particular helpful
when debugging the GuC firmware and can be enabled via
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS kernel config option.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 6 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 14 ++
drivers/gpu/drm/i915/i915_trace.h | 148 +-
3 files changed, 166 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 7f97753ab164..b24a1b7a3f88 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -8,6 +8,7 @@
#include "i915_drv.h"
#include "i915_globals.h"
+#include "i915_trace.h"
#include "intel_context.h"
#include "intel_engine.h"
@@ -28,6 +29,7 @@ static void rcu_context_free(struct rcu_head *rcu)
{
struct intel_context *ce = container_of(rcu, typeof(*ce), rcu);
+ trace_intel_context_free(ce);
kmem_cache_free(global.slab_ce, ce);
}
@@ -46,6 +48,7 @@ intel_context_create(struct intel_engine_cs *engine)
return ERR_PTR(-ENOMEM);
intel_context_init(ce, engine);
+ trace_intel_context_create(ce);
return ce;
}
@@ -268,6 +271,8 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
+ trace_intel_context_do_pin(ce);
+
err_unlock:
mutex_unlock(&ce->pin_mutex);
err_post_unpin:
@@ -323,6 +328,7 @@ void __intel_context_do_unpin(struct intel_context *ce, int
sub)
*/
intel_context_get(ce);
intel_context_active_release(ce);
+ trace_intel_context_do_unpin(ce);
intel_context_put(ce);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index c2327eebc09c..d605af0d66e6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -348,6 +348,7 @@ static int guc_add_request(struct intel_guc *guc, struct
i915_request *rq)
err = intel_guc_send_nb(guc, action, len, g2h_len_dw);
if (!enabled && !err) {
+ trace_intel_context_sched_enable(ce);
atomic_inc(&guc->outstanding_submission_g2h);
set_context_enabled(ce);
} else if (!enabled) {
@@ -812,6 +813,8 @@ static int register_context(struct intel_context *ce)
u32 offset = intel_guc_ggtt_offset(guc, guc->lrc_desc_pool) +
ce->guc_id * sizeof(struct guc_lrc_desc);
+ trace_intel_context_register(ce);
+
return __guc_action_register_context(guc, ce->guc_id, offset);
}
@@ -831,6 +834,8 @@ static int deregister_context(struct intel_context *ce, u32
guc_id)
{
struct intel_guc *guc = ce_to_guc(ce);
+ trace_intel_context_deregister(ce);
+
return __guc_action_deregister_context(guc, guc_id);
}
@@ -905,6 +910,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce)
* GuC before registering this context.
*/
if (context_registered) {
+ trace_intel_context_steal_guc_id(ce);
set_context_wait_for_deregister_to_register(ce);
intel_context_get(ce);
@@ -963,6 +969,7 @@ static void __guc_context_sched_disable(struct intel_guc
*guc,
GEM_BUG_ON(guc_id == GUC_INVALID_LRC_ID);
+ trace_intel_context_sched_disable(ce);
intel_context_get(ce);
guc_submission_busy_loop(guc, action, ARRAY_SIZE(action),
@@ -1119,6 +1126,9 @@ static void __guc_signal_context_fence(struct
intel_context *ce)
lockdep_assert_held(&ce->guc_state.lock);
+ if (!list_empty(&ce->guc_state.fences))
+ trace_intel_context_fence_release(ce);
+
list_for_each_entry(rq, &ce->guc_state.fences, guc_fence_link)
i915_sw_fence_complete(&rq->submit);
@@ -1529,6 +1539,8 @@ int intel_guc_deregister_done_process_msg(struct
intel_guc *guc,
if (unlikely(!ce))
return -EPROTO;
+ trace_intel_context_deregister_done(ce);
+
if (context_wait_for_deregister_to_register(ce)) {
struct intel_runtime_pm *runtime_pm =
&ce->engine->gt->i915->runtime_pm;
@@ -1580,6 +1592,8 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
return -EPROTO;
}
+ trace_intel_context_sched_done(ce);
+
if (context_pending_enable(ce)) {
clr_context_pending_enable(ce);
} else if (context_pending_disable(ce)) {
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index b02d04b6c8f6..97c2e83984ed 100644
--- a/drivers/gpu/drm/i915/i91
Re: [Intel-gfx] [PATCH 28/47] drm/i915: Hold reference to intel_context over life of i915_request
On 7/12/2021 14:36, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 08:05:30PM +, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:23:14AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Hold a reference to the intel_context over life of an i915_request.
Without this an i915_request can exist after the context has been
destroyed (e.g. request retired, context closed, but user space holds a
reference to the request from an out fence). In the case of GuC
submission + virtual engine, the engine that the request references is
also destroyed which can trigger bad pointer dref in fence ops (e.g.
Maybe quickly explain a why this is different for GuC submission vs
execlist? Presumably it is about only decomposing virtual engines to
physical ones in execlist mode?
Yes, it because in execlists we always end up pointing to a physical
engine in the end while in GuC mode we can be pointing to dynamically
allocated virtual engine. I can update the comment.
i915_fence_get_driver_name). We could likely change
i915_fence_get_driver_name to avoid touching the engine but let's just
be safe and hold the intel_context reference.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_request.c | 54 -
1 file changed, 22 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index de9deb95b8b1..dec5a35c9aa2 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -126,39 +126,17 @@ static void i915_fence_release(struct dma_fence *fence)
i915_sw_fence_fini(&rq->semaphore);
/*
-* Keep one request on each engine for reserved use under mempressure
-*
-* We do not hold a reference to the engine here and so have to be
-* very careful in what rq->engine we poke. The virtual engine is
-* referenced via the rq->context and we released that ref during
-* i915_request_retire(), ergo we must not dereference a virtual
-* engine here. Not that we would want to, as the only consumer of
-* the reserved engine->request_pool is the power management parking,
-* which must-not-fail, and that is only run on the physical engines.
-*
-* Since the request must have been executed to be have completed,
-* we know that it will have been processed by the HW and will
-* not be unsubmitted again, so rq->engine and rq->execution_mask
-* at this point is stable. rq->execution_mask will be a single
-* bit if the last and _only_ engine it could execution on was a
-* physical engine, if it's multiple bits then it started on and
-* could still be on a virtual engine. Thus if the mask is not a
-* power-of-two we assume that rq->engine may still be a virtual
-* engine and so a dangling invalid pointer that we cannot dereference
-*
-* For example, consider the flow of a bonded request through a virtual
-* engine. The request is created with a wide engine mask (all engines
-* that we might execute on). On processing the bond, the request mask
-* is reduced to one or more engines. If the request is subsequently
-* bound to a single engine, it will then be constrained to only
-* execute on that engine and never returned to the virtual engine
-* after timeslicing away, see __unwind_incomplete_requests(). Thus we
-* know that if the rq->execution_mask is a single bit, rq->engine
-* can be a physical engine with the exact corresponding mask.
+* Keep one request on each engine for reserved use under mempressure,
+* do not use with virtual engines as this really is only needed for
+* kernel contexts.
*/
- if (is_power_of_2(rq->execution_mask) &&
- !cmpxchg(&rq->engine->request_pool, NULL, rq))
+ if (!intel_engine_is_virtual(rq->engine) &&
+ !cmpxchg(&rq->engine->request_pool, NULL, rq)) {
+ intel_context_put(rq->context);
return;
+ }
+
+ intel_context_put(rq->context);
The put is actually unconditional? So it could be moved before the if?
Yep, I think so.
Wait nope. We reference rq->engine which could a virtual engine and the
intel_context_put could free that engine. So we need to do the put after
we reference it.
Matt
Doh! That's a pretty good reason.
Okay, with a tweaked description to explain about virtual engines being
different on GuC vs execlist...
Reviewed-by: John Harrison
Matt
John.
kmem_cache_free(global.slab_requests, rq);
}
@@ -977,7 +955,18 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
}
}
- rq->context = ce;
+ /*
+* Hold a reference to the intel_context over life of an i915_request.
+* Without this an i915_request can exist after the context has b
Re: [Intel-gfx] [PATCH 25/47] drm/i915: Add intel_context tracing
On Mon, Jul 12, 2021 at 11:10:40AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Add intel_context tracing. These trace points are particular helpful
> > when debugging the GuC firmware and can be enabled via
> > CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS kernel config option.
> >
> > Cc: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 6 +
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 14 ++
> > drivers/gpu/drm/i915/i915_trace.h | 148 +-
> > 3 files changed, 166 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index 7f97753ab164..b24a1b7a3f88 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -8,6 +8,7 @@
> > #include "i915_drv.h"
> > #include "i915_globals.h"
> > +#include "i915_trace.h"
> > #include "intel_context.h"
> > #include "intel_engine.h"
> > @@ -28,6 +29,7 @@ static void rcu_context_free(struct rcu_head *rcu)
> > {
> > struct intel_context *ce = container_of(rcu, typeof(*ce), rcu);
> > + trace_intel_context_free(ce);
> > kmem_cache_free(global.slab_ce, ce);
> > }
> > @@ -46,6 +48,7 @@ intel_context_create(struct intel_engine_cs *engine)
> > return ERR_PTR(-ENOMEM);
> > intel_context_init(ce, engine);
> > + trace_intel_context_create(ce);
> > return ce;
> > }
> > @@ -268,6 +271,8 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
> > GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
> > + trace_intel_context_do_pin(ce);
> > +
> > err_unlock:
> > mutex_unlock(&ce->pin_mutex);
> > err_post_unpin:
> > @@ -323,6 +328,7 @@ void __intel_context_do_unpin(struct intel_context *ce,
> > int sub)
> > */
> > intel_context_get(ce);
> > intel_context_active_release(ce);
> > + trace_intel_context_do_unpin(ce);
> > intel_context_put(ce);
> > }
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index c2327eebc09c..d605af0d66e6 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -348,6 +348,7 @@ static int guc_add_request(struct intel_guc *guc,
> > struct i915_request *rq)
> > err = intel_guc_send_nb(guc, action, len, g2h_len_dw);
> > if (!enabled && !err) {
> > + trace_intel_context_sched_enable(ce);
> > atomic_inc(&guc->outstanding_submission_g2h);
> > set_context_enabled(ce);
> > } else if (!enabled) {
> > @@ -812,6 +813,8 @@ static int register_context(struct intel_context *ce)
> > u32 offset = intel_guc_ggtt_offset(guc, guc->lrc_desc_pool) +
> > ce->guc_id * sizeof(struct guc_lrc_desc);
> > + trace_intel_context_register(ce);
> > +
> > return __guc_action_register_context(guc, ce->guc_id, offset);
> > }
> > @@ -831,6 +834,8 @@ static int deregister_context(struct intel_context *ce,
> > u32 guc_id)
> > {
> > struct intel_guc *guc = ce_to_guc(ce);
> > + trace_intel_context_deregister(ce);
> > +
> > return __guc_action_deregister_context(guc, guc_id);
> > }
> > @@ -905,6 +910,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce)
> > * GuC before registering this context.
> > */
> > if (context_registered) {
> > + trace_intel_context_steal_guc_id(ce);
> > set_context_wait_for_deregister_to_register(ce);
> > intel_context_get(ce);
> > @@ -963,6 +969,7 @@ static void __guc_context_sched_disable(struct
> > intel_guc *guc,
> > GEM_BUG_ON(guc_id == GUC_INVALID_LRC_ID);
> > + trace_intel_context_sched_disable(ce);
> > intel_context_get(ce);
> > guc_submission_busy_loop(guc, action, ARRAY_SIZE(action),
> > @@ -1119,6 +1126,9 @@ static void __guc_signal_context_fence(struct
> > intel_context *ce)
> > lockdep_assert_held(&ce->guc_state.lock);
> > + if (!list_empty(&ce->guc_state.fences))
> > + trace_intel_context_fence_release(ce);
> > +
> > list_for_each_entry(rq, &ce->guc_state.fences, guc_fence_link)
> > i915_sw_fence_complete(&rq->submit);
> > @@ -1529,6 +1539,8 @@ int intel_guc_deregister_done_process_msg(struct
> > intel_guc *guc,
> > if (unlikely(!ce))
> > return -EPROTO;
> > + trace_intel_context_deregister_done(ce);
> > +
> > if (context_wait_for_deregister_to_register(ce)) {
> > struct intel_runtime_pm *runtime_pm =
> > &ce->engine->gt->i915->runtime_pm;
> > @@ -1580,6 +1592,8 @@ int intel_guc_sched_done_process_msg(struct intel_guc
> > *guc,
> > return -EPROTO;
> > }
> > + trace_intel_context_sched_done(ce);
> > +
> > if (context_pending_enable(ce)) {
> > clr_context_pending_enable(ce);
> > } else i
Re: [Intel-gfx] [PATCH 23/47] drm/i915/guc: Update GuC debugfs to support new GuC
On 7/12/2021 13:59, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:05:59AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Update GuC debugfs to support the new GuC structures.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 22
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 ++
.../gpu/drm/i915/gt/uc/intel_guc_debugfs.c| 23 +++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 52 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 4 ++
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
6 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index e0f92e28350c..4ed074df88e5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -1135,3 +1135,25 @@ void intel_guc_ct_event_handler(struct intel_guc_ct *ct)
ct_try_receive_message(ct);
}
+
+void intel_guc_log_ct_info(struct intel_guc_ct *ct,
+ struct drm_printer *p)
+{
+ if (!ct->enabled) {
+ drm_puts(p, "CT disabled\n");
+ return;
+ }
+
+ drm_printf(p, "H2G Space: %u\n",
+ atomic_read(&ct->ctbs.send.space) * 4);
+ drm_printf(p, "Head: %u\n",
+ ct->ctbs.send.desc->head);
+ drm_printf(p, "Tail: %u\n",
+ ct->ctbs.send.desc->tail);
+ drm_printf(p, "G2H Space: %u\n",
+ atomic_read(&ct->ctbs.recv.space) * 4);
+ drm_printf(p, "Head: %u\n",
+ ct->ctbs.recv.desc->head);
+ drm_printf(p, "Tail: %u\n",
+ ct->ctbs.recv.desc->tail);
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index ab1b79ab960b..f62eb06b32fc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -16,6 +16,7 @@
struct i915_vma;
struct intel_guc;
+struct drm_printer;
/**
* DOC: Command Transport (CT).
@@ -106,4 +107,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32
*action, u32 len,
u32 *response_buf, u32 response_buf_size, u32 flags);
void intel_guc_ct_event_handler(struct intel_guc_ct *ct);
+void intel_guc_log_ct_info(struct intel_guc_ct *ct, struct drm_printer *p);
+
#endif /* _INTEL_GUC_CT_H_ */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
index fe7cb7b29a1e..62b9ce0fafaa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
@@ -9,6 +9,8 @@
#include "intel_guc.h"
#include "intel_guc_debugfs.h"
#include "intel_guc_log_debugfs.h"
+#include "gt/uc/intel_guc_ct.h"
+#include "gt/uc/intel_guc_submission.h"
static int guc_info_show(struct seq_file *m, void *data)
{
@@ -22,16 +24,35 @@ static int guc_info_show(struct seq_file *m, void *data)
drm_puts(&p, "\n");
intel_guc_log_info(&guc->log, &p);
- /* Add more as required ... */
+ if (!intel_guc_submission_is_used(guc))
+ return 0;
+
+ intel_guc_log_ct_info(&guc->ct, &p);
+ intel_guc_log_submission_info(guc, &p);
return 0;
}
DEFINE_GT_DEBUGFS_ATTRIBUTE(guc_info);
+static int guc_registered_contexts_show(struct seq_file *m, void *data)
+{
+ struct intel_guc *guc = m->private;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ if (!intel_guc_submission_is_used(guc))
+ return -ENODEV;
+
+ intel_guc_log_context_info(guc, &p);
+
+ return 0;
+}
+DEFINE_GT_DEBUGFS_ATTRIBUTE(guc_registered_contexts);
+
void intel_guc_debugfs_register(struct intel_guc *guc, struct dentry *root)
{
static const struct debugfs_gt_file files[] = {
{ "guc_info", &guc_info_fops, NULL },
+ { "guc_registered_contexts", &guc_registered_contexts_fops,
NULL },
};
if (!intel_guc_is_supported(guc))
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index d1a28283a9ae..89b3c7e5d15b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1600,3 +1600,55 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
return 0;
}
+
+void intel_guc_log_submission_info(struct intel_guc *guc,
+ struct drm_printer *p)
+{
+ struct i915_sched_engine *sched_engine = guc->sched_engine;
+ struct rb_node *rb;
+ unsigned long flags;
+
+ drm_printf(p, "GuC Number Outstanding Submission G2H: %u\n",
+ atomic_read(&guc->outstanding_submission_g2h));
+ drm_printf(p, "GuC tasklet count: %u\n\n",
+ atomic_read(&sched_en
Re: [Intel-gfx] [PATCH 28/47] drm/i915: Hold reference to intel_context over life of i915_request
On Mon, Jul 12, 2021 at 08:05:30PM +, Matthew Brost wrote:
> On Mon, Jul 12, 2021 at 11:23:14AM -0700, John Harrison wrote:
> > On 6/24/2021 00:04, Matthew Brost wrote:
> > > Hold a reference to the intel_context over life of an i915_request.
> > > Without this an i915_request can exist after the context has been
> > > destroyed (e.g. request retired, context closed, but user space holds a
> > > reference to the request from an out fence). In the case of GuC
> > > submission + virtual engine, the engine that the request references is
> > > also destroyed which can trigger bad pointer dref in fence ops (e.g.
> > Maybe quickly explain a why this is different for GuC submission vs
> > execlist? Presumably it is about only decomposing virtual engines to
> > physical ones in execlist mode?
> >
>
> Yes, it because in execlists we always end up pointing to a physical
> engine in the end while in GuC mode we can be pointing to dynamically
> allocated virtual engine. I can update the comment.
>
> >
> > > i915_fence_get_driver_name). We could likely change
> > > i915_fence_get_driver_name to avoid touching the engine but let's just
> > > be safe and hold the intel_context reference.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/i915_request.c | 54 -
> > > 1 file changed, 22 insertions(+), 32 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > > b/drivers/gpu/drm/i915/i915_request.c
> > > index de9deb95b8b1..dec5a35c9aa2 100644
> > > --- a/drivers/gpu/drm/i915/i915_request.c
> > > +++ b/drivers/gpu/drm/i915/i915_request.c
> > > @@ -126,39 +126,17 @@ static void i915_fence_release(struct dma_fence
> > > *fence)
> > > i915_sw_fence_fini(&rq->semaphore);
> > > /*
> > > - * Keep one request on each engine for reserved use under mempressure
> > > - *
> > > - * We do not hold a reference to the engine here and so have to be
> > > - * very careful in what rq->engine we poke. The virtual engine is
> > > - * referenced via the rq->context and we released that ref during
> > > - * i915_request_retire(), ergo we must not dereference a virtual
> > > - * engine here. Not that we would want to, as the only consumer of
> > > - * the reserved engine->request_pool is the power management parking,
> > > - * which must-not-fail, and that is only run on the physical engines.
> > > - *
> > > - * Since the request must have been executed to be have completed,
> > > - * we know that it will have been processed by the HW and will
> > > - * not be unsubmitted again, so rq->engine and rq->execution_mask
> > > - * at this point is stable. rq->execution_mask will be a single
> > > - * bit if the last and _only_ engine it could execution on was a
> > > - * physical engine, if it's multiple bits then it started on and
> > > - * could still be on a virtual engine. Thus if the mask is not a
> > > - * power-of-two we assume that rq->engine may still be a virtual
> > > - * engine and so a dangling invalid pointer that we cannot dereference
> > > - *
> > > - * For example, consider the flow of a bonded request through a virtual
> > > - * engine. The request is created with a wide engine mask (all engines
> > > - * that we might execute on). On processing the bond, the request mask
> > > - * is reduced to one or more engines. If the request is subsequently
> > > - * bound to a single engine, it will then be constrained to only
> > > - * execute on that engine and never returned to the virtual engine
> > > - * after timeslicing away, see __unwind_incomplete_requests(). Thus we
> > > - * know that if the rq->execution_mask is a single bit, rq->engine
> > > - * can be a physical engine with the exact corresponding mask.
> > > + * Keep one request on each engine for reserved use under mempressure,
> > > + * do not use with virtual engines as this really is only needed for
> > > + * kernel contexts.
> > >*/
> > > - if (is_power_of_2(rq->execution_mask) &&
> > > - !cmpxchg(&rq->engine->request_pool, NULL, rq))
> > > + if (!intel_engine_is_virtual(rq->engine) &&
> > > + !cmpxchg(&rq->engine->request_pool, NULL, rq)) {
> > > + intel_context_put(rq->context);
> > > return;
> > > + }
> > > +
> > > + intel_context_put(rq->context);
> > The put is actually unconditional? So it could be moved before the if?
> >
>
> Yep, I think so.
>
Wait nope. We reference rq->engine which could a virtual engine and the
intel_context_put could free that engine. So we need to do the put after
we reference it.
Matt
> Matt
>
> > John.
> >
> > > kmem_cache_free(global.slab_requests, rq);
> > > }
> > > @@ -977,7 +955,18 @@ __i915_request_create(struct intel_context *ce,
> > > gfp_t gfp)
> > > }
> > > }
> > > - rq->context = ce;
> > > + /*
> > > + * Hold a reference to the intel_context over life of an i915_request.
> > > + * Without this
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Silence __iomem sparse warn
== Series Details == Series: series starting with [1/2] drm/i915: Silence __iomem sparse warn URL : https://patchwork.freedesktop.org/series/92443/ State : success == Summary == CI Bug Log - changes from CI_DRM_10334_full -> Patchwork_20577_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20577_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@idempotent: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-snb2/igt@gem_ctx_persiste...@idempotent.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][2] -> [FAIL][3] ([i915#2842]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: NOTRUN -> [FAIL][4] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-kbl7/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2849]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_mmap_gtt@big-copy-odd: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#307]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-glk7/igt@gem_mmap_...@big-copy-odd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-glk4/igt@gem_mmap_...@big-copy-odd.html * igt@gem_mmap_gtt@cpuset-big-copy-xy: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2428]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-iclb4/igt@gem_mmap_...@cpuset-big-copy-xy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-iclb8/igt@gem_mmap_...@cpuset-big-copy-xy.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][13] ([i915#2658]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-snb5/igt@gem_pwr...@basic-exhaustion.html * igt@gen9_exec_parse@batch-without-end: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#112306]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-iclb7/igt@gen9_exec_pa...@batch-without-end.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-iclb: NOTRUN -> [WARN][15] ([i915#1804] / [i915#2684]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-iclb7/igt@i915_pm_rc6_reside...@rc6-fence.html * igt@i915_selftest@live@hangcheck: - shard-snb: NOTRUN -> [INCOMPLETE][16] ([i915#2782]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-snb6/igt@i915_selftest@l...@hangcheck.html * igt@kms_big_fb@y-tiled-32bpp-rotate-0: - shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#118] / [i915#95]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-glk5/igt@kms_big...@y-tiled-32bpp-rotate-0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-glk7/igt@kms_big...@y-tiled-32bpp-rotate-0.html * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271]) +166 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-apl1/igt@kms_big...@yf-tiled-max-hw-stride-64bpp-rotate-0.html * igt@kms_chamelium@hdmi-hpd-enable-disable-mode: - shard-snb: NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) +19 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-snb2/igt@kms_chamel...@hdmi-hpd-enable-disable-mode.html * igt@kms_chamelium@vga-edid-read: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +15 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-apl7/igt@kms_chamel...@vga-edid-read.html * igt@kms_chamelium@vga-hpd: - shard-skl: NOTRUN -> [SKIP][22] ([fdo#109271] / [fdo#111827]) +3 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/shard-skl3/igt@
Re: [Intel-gfx] [PATCH v4 01/18] drm/sched: Split drm_sched_job_init
On Mon, Jul 12, 2021 at 1:01 PM Daniel Vetter wrote: > > This is a very confusingly named function, because not just does it > init an object, it arms it and provides a point of no return for > pushing a job into the scheduler. It would be nice if that's a bit > clearer in the interface. > > But the real reason is that I want to push the dependency tracking > helpers into the scheduler code, and that means drm_sched_job_init > must be called a lot earlier, without arming the job. > > v2: > - don't change .gitignore (Steven) > - don't forget v3d (Emma) > > v3: Emma noticed that I leak the memory allocated in > drm_sched_job_init if we bail out before the point of no return in > subsequent driver patches. To be able to fix this change > drm_sched_job_cleanup() so it can handle being called both before and > after drm_sched_job_arm(). > > Also improve the kerneldoc for this. > > v4: > - Fix the drm_sched_job_cleanup logic, I inverted the booleans, as > usual (Melissa) > > - Christian pointed out that drm_sched_entity_select_rq() also needs > to be moved into drm_sched_job_arm, which made me realize that the > job->id definitely needs to be moved too. > > Shuffle things to fit between job_init and job_arm. > > v5: > Reshuffle the split between init/arm once more, amdgpu abuses > drm_sched.ready to signal gpu reset failures. Also document this > somewhat. (Christian) Ack from me for the changes I was Cced on. ___ 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/sched dependency tracking and dma-resv fixes (rev3)
== Series Details == Series: drm/sched dependency tracking and dma-resv fixes (rev3) URL : https://patchwork.freedesktop.org/series/92333/ State : success == Summary == CI Bug Log - changes from CI_DRM_10335 -> Patchwork_20579 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/index.html Changes --- No changes found Participating hosts (40 -> 39) -- Missing(1): fi-bdw-samus Build changes - * Linux: CI_DRM_10335 -> Patchwork_20579 CI-20190529: 20190529 CI_DRM_10335: 6420d4c905cfd9a9098c7ab339992eafa628de4d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6134: cd63c83e23789eb194d38b8d272247a88122f2f6 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20579: d021158c3459d5aac4284f2c2d1ba6d2a3224523 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d021158c3459 dma-resv: Give the docs a do-over e5108682 drm/i915: Don't break exclusive fence ordering d071ad427447 drm/i915: delete exclude argument from i915_sw_fence_await_reservation 62518f586849 drm/etnaviv: Don't break exclusive fence ordering cacd99895adb drm/msm: Don't break exclusive fence ordering bf91d1bed9e0 drm/sched: Check locking in drm_sched_job_await_implicit a29b9a4e9a6f drm/sched: Don't store self-dependencies 10bbe7e47ff2 drm/gem: Delete gem array fencing helpers f2e5d8c0db05 drm/etnaviv: Use scheduler dependency handling ec9e93816f9b drm/v3d: Use scheduler dependency handling b021a09fdfd1 drm/v3d: Move drm_sched_job_init to v3d_job_init c7f6cb0870bb drm/lima: use scheduler dependency tracking 029320ff7db6 drm/panfrost: use scheduler dependency tracking a1900803cd8b drm/sched: improve docs around drm_sched_entity 8a6181903dc0 drm/sched: drop entity parameter from drm_sched_push_job 1117822b2255 drm/sched: Add dependency tracking cd01cdfb93e7 drm/sched: Barriers are needed for entity->last_scheduled fa00bbda8116 drm/sched: Split drm_sched_job_init == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20579/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/12] drm/i915/glk: Use revid->stepping tables
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Roper, Matthew D
>
> Subject: [PATCH v2 06/12] drm/i915/glk: Use revid->stepping tables
>
> Switch GLK to use a revid->stepping table as we're trying to do on all
> platforms going forward. Pre-production and placeholder revisions are
> omitted.
>
> Although nothing in the code is using the data from this table at the moment,
> we expect some upcoming DMC patches to start utilizing it.
>
> Bspec: 19131
> Cc: Anusha Srivatsa
> Signed-off-by: Matt Roper
> ---
Reviewed-by: Anusha Srivatsa
> drivers/gpu/drm/i915/i915_drv.h | 8
> drivers/gpu/drm/i915/intel_step.c | 7 +++
> 2 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index afb159f2a658..dac9ed2dfca5
> 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1522,14 +1522,6 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915, #define IS_KBL_DISPLAY_STEP(dev_priv, since, until) \
> (IS_KABYLAKE(dev_priv) && IS_DISPLAY_STEP(dev_priv, since,
> until))
>
> -#define GLK_REVID_A0 0x0
> -#define GLK_REVID_A1 0x1
> -#define GLK_REVID_A2 0x2
> -#define GLK_REVID_B0 0x3
> -
> -#define IS_GLK_REVID(dev_priv, since, until) \
> - (IS_GEMINILAKE(dev_priv) && IS_REVID(dev_priv, since, until))
> -
> #define CNL_REVID_A0 0x0
> #define CNL_REVID_B0 0x1
> #define CNL_REVID_C0 0x2
> diff --git a/drivers/gpu/drm/i915/intel_step.c
> b/drivers/gpu/drm/i915/intel_step.c
> index 41e3904ae6e8..7f8fe5e4c039 100644
> --- a/drivers/gpu/drm/i915/intel_step.c
> +++ b/drivers/gpu/drm/i915/intel_step.c
> @@ -49,6 +49,10 @@ static const struct intel_step_info bxt_revids[] = {
> [0xD] = { COMMON_STEPPING(E0) },
> };
>
> +static const struct intel_step_info glk_revids[] = {
> + [3] = { COMMON_STEPPING(B0) },
> +};
> +
> static const struct intel_step_info tgl_uy_revids[] = {
> [0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
> [1] = { .gt_step = STEP_B0, .display_step = STEP_C0 }, @@ -96,6
> +100,9 @@ void intel_step_init(struct drm_i915_private *i915)
> } else if (IS_TIGERLAKE(i915)) {
> revids = tgl_revids;
> size = ARRAY_SIZE(tgl_revids);
> + } else if (IS_GEMINILAKE(i915)) {
> + revids = glk_revids;
> + size = ARRAY_SIZE(glk_revids);
> } else if (IS_BROXTON(i915)) {
> revids = bxt_revids;
> size = ARRAY_SIZE(bxt_revids);
> --
> 2.25.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Make pre-production detection use direct revid comparison
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:43 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Jani Nikula
> Subject: Re: [Intel-gfx] [PATCH 1/7] drm/i915: Make pre-production
> detection use direct revid comparison
>
> On Thu, Jul 08, 2021 at 11:08:46AM -0700, Srivatsa, Anusha wrote:
> >
> >
> > > -Original Message-
> > > From: Intel-gfx On Behalf
> > > Of Matt Roper
> > > Sent: Wednesday, July 7, 2021 10:38 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Subject: [Intel-gfx] [PATCH 1/7] drm/i915: Make pre-production
> > > detection use direct revid comparison
> > >
> > > Although we're converting our workarounds to use a revid->stepping
> > > lookup table, the function that detects pre-production hardware
> > > should continue to compare against PCI revision ID values directly.
> > > These are listed in the bspec as integers, so it's easier to confirm
> > > their correctness if we just use an integer literal rather than a symbolic
> name anyway.
> > >
> > > Since the BXT, GLK, and CNL revid macros were never used in any
> > > workaround code, just remove them completely.
> > >
> > > Bspec: 13620, 19131, 13626, 18329
> > > Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.c | 8
> > > drivers/gpu/drm/i915/i915_drv.h | 24
> > > drivers/gpu/drm/i915/intel_step.h | 1 +
> > > 3 files changed, 5 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c index 30d8cd8c69b1..90136995f5eb
> > > 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -271,10 +271,10 @@ static void
> > > intel_detect_preproduction_hw(struct
> > > drm_i915_private *dev_priv)
> > > bool pre = false;
> > >
> > > pre |= IS_HSW_EARLY_SDV(dev_priv);
> > > - pre |= IS_SKL_REVID(dev_priv, 0, SKL_REVID_F0);
> > > - pre |= IS_BXT_REVID(dev_priv, 0, BXT_REVID_B_LAST);
> > > - pre |= IS_KBL_GT_STEP(dev_priv, 0, STEP_A0);
> > > - pre |= IS_GLK_REVID(dev_priv, 0, GLK_REVID_A2);
> > > + pre |= IS_SKYLAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x6;
> > > + pre |= IS_BROXTON(dev_priv) && INTEL_REVID(dev_priv) < 0xA;
> > > + pre |= IS_KABYLAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x1;
> > > + pre |= IS_GEMINILAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x3;
> > >
> > > if (pre) {
> > > drm_err(&dev_priv->drm, "This is a pre-production stepping.
> > > "
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h index 6dff4ca01241..796e6838bc79
> > > 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1473,35 +1473,11 @@ IS_SUBPLATFORM(const struct
> drm_i915_private
> > > *i915,
> > >
> > > #define IS_SKL_REVID(p, since, until) (IS_SKYLAKE(p) && IS_REVID(p,
> > > since,
> > > until))
> > >
> > > -#define BXT_REVID_A0 0x0
> > > -#define BXT_REVID_A1 0x1
> > > -#define BXT_REVID_B0 0x3
> > > -#define BXT_REVID_B_LAST 0x8
> > > -#define BXT_REVID_C0 0x9
> > > -
> > > -#define IS_BXT_REVID(dev_priv, since, until) \
> > > - (IS_BROXTON(dev_priv) && IS_REVID(dev_priv, since, until))
> >
> > Here, we can have IS_BXT_GT_STEP, similar to other platform and use in
> intel_detect_preproduction_hw() above.
> > Same for other platforms - SKL and GLK. KBL already uses IS_KBL_GT_STEP.
>
> Are you going to use that macro in your DMC code? If not, there's no need
> for it since we don't have any stepping-specific workarounds on BXT that
> would use the macro. For now I've only kept the GT and/or display stepping
> macros on platforms that will actually use them (like KBL).
>
> I just sent a v2 of the series that I think should be suitable for you to
> build
> your DMC work on top of (and I included one of the patches from your series
> at the beginning of mine). Note that I punted on adding tables for
> CFL/WHL/AML/CML because the steppings on those platforms are a bit
> weird and I'm not sure exactly what you'll need from the DMC side of things.
> We don't need the tables on those platforms for workarounds, so you can
> add them with your DMC series when you know exactly how you need the
> data presented.
>
>
> Matt
>
> >
> > Anusha
> > > #define IS_KBL_GT_STEP(dev_priv, since, until) \
> > > (IS_KABYLAKE(dev_priv) && IS_GT_STEP(dev_priv, since, until))
> > > #define IS_KBL_DISPLAY_STEP(dev_priv, since, until) \
> > > (IS_KABYLAKE(dev_priv) && IS_DISPLAY_STEP(dev_priv, since,
> > > until))
> > >
> > > -#define GLK_REVID_A0 0x0
> > > -#define GLK_REVID_A1 0x1
> > > -#define GLK_REVID_A2 0x2
> > > -#define GLK_REVID_B0 0x3
> > > -
> > > -#define IS_GLK_REVID(dev_priv, since, until) \
> > > - (IS_GEMINILAKE(dev_priv) && IS_REVID(dev_priv, since, until))
> > > -
> > > -#define CNL_
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Make pre-production detection use direct revid comparison
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, July 9, 2021 8:43 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Jani Nikula
> Subject: Re: [Intel-gfx] [PATCH 1/7] drm/i915: Make pre-production
> detection use direct revid comparison
>
> On Thu, Jul 08, 2021 at 11:08:46AM -0700, Srivatsa, Anusha wrote:
> >
> >
> > > -Original Message-
> > > From: Intel-gfx On Behalf
> > > Of Matt Roper
> > > Sent: Wednesday, July 7, 2021 10:38 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Subject: [Intel-gfx] [PATCH 1/7] drm/i915: Make pre-production
> > > detection use direct revid comparison
> > >
> > > Although we're converting our workarounds to use a revid->stepping
> > > lookup table, the function that detects pre-production hardware
> > > should continue to compare against PCI revision ID values directly.
> > > These are listed in the bspec as integers, so it's easier to confirm
> > > their correctness if we just use an integer literal rather than a symbolic
> name anyway.
> > >
> > > Since the BXT, GLK, and CNL revid macros were never used in any
> > > workaround code, just remove them completely.
> > >
> > > Bspec: 13620, 19131, 13626, 18329
> > > Signed-off-by: Matt Roper
Reviewed-by: Anusha Srivatsa
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.c | 8
> > > drivers/gpu/drm/i915/i915_drv.h | 24
> > > drivers/gpu/drm/i915/intel_step.h | 1 +
> > > 3 files changed, 5 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c index 30d8cd8c69b1..90136995f5eb
> > > 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -271,10 +271,10 @@ static void
> > > intel_detect_preproduction_hw(struct
> > > drm_i915_private *dev_priv)
> > > bool pre = false;
> > >
> > > pre |= IS_HSW_EARLY_SDV(dev_priv);
> > > - pre |= IS_SKL_REVID(dev_priv, 0, SKL_REVID_F0);
> > > - pre |= IS_BXT_REVID(dev_priv, 0, BXT_REVID_B_LAST);
> > > - pre |= IS_KBL_GT_STEP(dev_priv, 0, STEP_A0);
> > > - pre |= IS_GLK_REVID(dev_priv, 0, GLK_REVID_A2);
> > > + pre |= IS_SKYLAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x6;
> > > + pre |= IS_BROXTON(dev_priv) && INTEL_REVID(dev_priv) < 0xA;
> > > + pre |= IS_KABYLAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x1;
> > > + pre |= IS_GEMINILAKE(dev_priv) && INTEL_REVID(dev_priv) < 0x3;
> > >
> > > if (pre) {
> > > drm_err(&dev_priv->drm, "This is a pre-production stepping.
> > > "
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h index 6dff4ca01241..796e6838bc79
> > > 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1473,35 +1473,11 @@ IS_SUBPLATFORM(const struct
> drm_i915_private
> > > *i915,
> > >
> > > #define IS_SKL_REVID(p, since, until) (IS_SKYLAKE(p) && IS_REVID(p,
> > > since,
> > > until))
> > >
> > > -#define BXT_REVID_A0 0x0
> > > -#define BXT_REVID_A1 0x1
> > > -#define BXT_REVID_B0 0x3
> > > -#define BXT_REVID_B_LAST 0x8
> > > -#define BXT_REVID_C0 0x9
> > > -
> > > -#define IS_BXT_REVID(dev_priv, since, until) \
> > > - (IS_BROXTON(dev_priv) && IS_REVID(dev_priv, since, until))
> >
> > Here, we can have IS_BXT_GT_STEP, similar to other platform and use in
> intel_detect_preproduction_hw() above.
> > Same for other platforms - SKL and GLK. KBL already uses IS_KBL_GT_STEP.
>
> Are you going to use that macro in your DMC code? If not, there's no need
> for it since we don't have any stepping-specific workarounds on BXT that
> would use the macro. For now I've only kept the GT and/or display stepping
> macros on platforms that will actually use them (like KBL).
>
> I just sent a v2 of the series that I think should be suitable for you to
> build
> your DMC work on top of (and I included one of the patches from your series
> at the beginning of mine). Note that I punted on adding tables for
> CFL/WHL/AML/CML because the steppings on those platforms are a bit
> weird and I'm not sure exactly what you'll need from the DMC side of things.
> We don't need the tables on those platforms for workarounds, so you can
> add them with your DMC series when you know exactly how you need the
> data presented.
>
>
> Matt
>
> >
> > Anusha
> > > #define IS_KBL_GT_STEP(dev_priv, since, until) \
> > > (IS_KABYLAKE(dev_priv) && IS_GT_STEP(dev_priv, since, until))
> > > #define IS_KBL_DISPLAY_STEP(dev_priv, since, until) \
> > > (IS_KABYLAKE(dev_priv) && IS_DISPLAY_STEP(dev_priv, since,
> > > until))
> > >
> > > -#define GLK_REVID_A0 0x0
> > > -#define GLK_REVID_A1 0x1
> > > -#define GLK_REVID_A2 0x2
> > > -#define GLK_REVID_B0 0x3
> > > -
> > > -#define IS_GLK_REVID(dev_priv, since, until) \
> > > - (IS_GEMINILAKE(dev_priv) && IS_REVID(dev_priv, since, until))
> > > -
> > > -#define CNL_
Re: [Intel-gfx] [PATCH 23/47] drm/i915/guc: Update GuC debugfs to support new GuC
On Mon, Jul 12, 2021 at 11:05:59AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Update GuC debugfs to support the new GuC structures.
> >
> > Signed-off-by: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 22
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 ++
> > .../gpu/drm/i915/gt/uc/intel_guc_debugfs.c| 23 +++-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 52 +++
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 4 ++
> > drivers/gpu/drm/i915/i915_debugfs.c | 1 +
> > 6 files changed, 104 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index e0f92e28350c..4ed074df88e5 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -1135,3 +1135,25 @@ void intel_guc_ct_event_handler(struct intel_guc_ct
> > *ct)
> > ct_try_receive_message(ct);
> > }
> > +
> > +void intel_guc_log_ct_info(struct intel_guc_ct *ct,
> > + struct drm_printer *p)
> > +{
> > + if (!ct->enabled) {
> > + drm_puts(p, "CT disabled\n");
> > + return;
> > + }
> > +
> > + drm_printf(p, "H2G Space: %u\n",
> > + atomic_read(&ct->ctbs.send.space) * 4);
> > + drm_printf(p, "Head: %u\n",
> > + ct->ctbs.send.desc->head);
> > + drm_printf(p, "Tail: %u\n",
> > + ct->ctbs.send.desc->tail);
> > + drm_printf(p, "G2H Space: %u\n",
> > + atomic_read(&ct->ctbs.recv.space) * 4);
> > + drm_printf(p, "Head: %u\n",
> > + ct->ctbs.recv.desc->head);
> > + drm_printf(p, "Tail: %u\n",
> > + ct->ctbs.recv.desc->tail);
> > +}
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> > index ab1b79ab960b..f62eb06b32fc 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> > @@ -16,6 +16,7 @@
> > struct i915_vma;
> > struct intel_guc;
> > +struct drm_printer;
> > /**
> >* DOC: Command Transport (CT).
> > @@ -106,4 +107,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const
> > u32 *action, u32 len,
> > u32 *response_buf, u32 response_buf_size, u32 flags);
> > void intel_guc_ct_event_handler(struct intel_guc_ct *ct);
> > +void intel_guc_log_ct_info(struct intel_guc_ct *ct, struct drm_printer *p);
> > +
> > #endif /* _INTEL_GUC_CT_H_ */
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
> > index fe7cb7b29a1e..62b9ce0fafaa 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
> > @@ -9,6 +9,8 @@
> > #include "intel_guc.h"
> > #include "intel_guc_debugfs.h"
> > #include "intel_guc_log_debugfs.h"
> > +#include "gt/uc/intel_guc_ct.h"
> > +#include "gt/uc/intel_guc_submission.h"
> > static int guc_info_show(struct seq_file *m, void *data)
> > {
> > @@ -22,16 +24,35 @@ static int guc_info_show(struct seq_file *m, void *data)
> > drm_puts(&p, "\n");
> > intel_guc_log_info(&guc->log, &p);
> > - /* Add more as required ... */
> > + if (!intel_guc_submission_is_used(guc))
> > + return 0;
> > +
> > + intel_guc_log_ct_info(&guc->ct, &p);
> > + intel_guc_log_submission_info(guc, &p);
> > return 0;
> > }
> > DEFINE_GT_DEBUGFS_ATTRIBUTE(guc_info);
> > +static int guc_registered_contexts_show(struct seq_file *m, void *data)
> > +{
> > + struct intel_guc *guc = m->private;
> > + struct drm_printer p = drm_seq_file_printer(m);
> > +
> > + if (!intel_guc_submission_is_used(guc))
> > + return -ENODEV;
> > +
> > + intel_guc_log_context_info(guc, &p);
> > +
> > + return 0;
> > +}
> > +DEFINE_GT_DEBUGFS_ATTRIBUTE(guc_registered_contexts);
> > +
> > void intel_guc_debugfs_register(struct intel_guc *guc, struct dentry
> > *root)
> > {
> > static const struct debugfs_gt_file files[] = {
> > { "guc_info", &guc_info_fops, NULL },
> > + { "guc_registered_contexts", &guc_registered_contexts_fops,
> > NULL },
> > };
> > if (!intel_guc_is_supported(guc))
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index d1a28283a9ae..89b3c7e5d15b 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -1600,3 +1600,55 @@ int intel_guc_sched_done_process_msg(struct
> > intel_guc *guc,
> > return 0;
> > }
> > +
> > +void intel_guc_log_submission_info(struct intel_guc *guc,
> > + struct drm_printer *p)
> > +{
> > + struct i915_sched_engine *sched_engine = guc->sched_engine;
> > + struct rb_n
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/sched dependency tracking and dma-resv fixes (rev3)
== Series Details ==
Series: drm/sched dependency tracking and dma-resv fixes (rev3)
URL : https://patchwork.freedesktop.org/series/92333/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fa00bbda8116 drm/sched: Split drm_sched_job_init
-:210: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#210: FILE: drivers/gpu/drm/scheduler/sched_fence.c:173:
+ unsigned seq;
-:306: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON &
recovery code rather than BUG() or BUG_ON()
#306: FILE: drivers/gpu/drm/scheduler/sched_main.c:623:
+ BUG_ON(!entity);
-:375: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#375: FILE: include/drm/gpu_scheduler.h:391:
+struct drm_sched_fence *drm_sched_fence_alloc(
-:383: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 3 warnings, 1 checks, 240 lines checked
cd01cdfb93e7 drm/sched: Barriers are needed for entity->last_scheduled
-:86: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 43 lines checked
1117822b2255 drm/sched: Add dependency tracking
-:193: CHECK:LINE_SPACING: Please don't use multiple blank lines
#193: FILE: drivers/gpu/drm/scheduler/sched_main.c:728:
+
+
-:268: WARNING:TYPO_SPELLING: 'ommitted' may be misspelled - perhaps 'omitted'?
#268: FILE: include/drm/gpu_scheduler.h:243:
+* drm_sched_job_await_implicit() this can be ommitted and left as NULL.
-:282: CHECK:LINE_SPACING: Please don't use multiple blank lines
#282: FILE: include/drm/gpu_scheduler.h:376:
+
+
-:285: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 2 warnings, 2 checks, 227 lines checked
8a6181903dc0 drm/sched: drop entity parameter from drm_sched_push_job
-:203: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 102 lines checked
a1900803cd8b drm/sched: improve docs around drm_sched_entity
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 620e762f9a98 ("drm/scheduler:
move entity handling into separate file")'
#14:
move here: 620e762f9a98 ("drm/scheduler: move entity handling into
-:396: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 346 lines checked
029320ff7db6 drm/panfrost: use scheduler dependency tracking
-:209: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 157 lines checked
c7f6cb0870bb drm/lima: use scheduler dependency tracking
-:114: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 73 lines checked
b021a09fdfd1 drm/v3d: Move drm_sched_job_init to v3d_job_init
-:356: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 302 lines checked
ec9e93816f9b drm/v3d: Use scheduler dependency handling
-:202: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 161 lines checked
f2e5d8c0db05 drm/etnaviv: Use scheduler dependency handling
-:13: WARNING:REPEATED_WORD: Possible repeated word: 'to'
#13:
I wanted to to in the previous round (and did, for all other drivers).
-:119: WARNING:LINE_SPACING: Missing a blank line after declarations
#119: FILE: drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c:551:
+ struct dma_fence *in_fence =
sync_file_get_fence(args->fence_fd);
+ if (!in_fence) {
-:293: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 3 warnings, 0 checks, 241 lines checked
10bbe7e47ff2 drm/gem: Delete gem array fencing helpers
-:141: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 14 lines checked
a29b9a4e9a6f drm/sched: Don't store self-dependencies
-:19: WARNING:TYPO_SPELLING: 'wont' may be misspelled - perhaps 'won't'?
#19:
drivers wont miss it.
-:47: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mism
Re: [Intel-gfx] [PATCH 33/47] drm/i915/guc: Add disable interrupts to guc sanitize
On 6/24/2021 00:05, Matthew Brost wrote:
Add disable GuC interrupts to intel_guc_sanitize(). Part of this
requires moving the guc_*_interrupt wrapper function into header file
intel_guc.h.
Signed-off-by: Matthew Brost
Cc: Daniele Ceraolo Spurio
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 16
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 21 +++--
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 40c9868762d7..85ef6767f13b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -217,9 +217,25 @@ static inline bool intel_guc_is_ready(struct intel_guc
*guc)
return intel_guc_is_fw_running(guc) && intel_guc_ct_enabled(&guc->ct);
}
+static inline void intel_guc_reset_interrupts(struct intel_guc *guc)
+{
+ guc->interrupts.reset(guc);
+}
+
+static inline void intel_guc_enable_interrupts(struct intel_guc *guc)
+{
+ guc->interrupts.enable(guc);
+}
+
+static inline void intel_guc_disable_interrupts(struct intel_guc *guc)
+{
+ guc->interrupts.disable(guc);
+}
+
static inline int intel_guc_sanitize(struct intel_guc *guc)
{
intel_uc_fw_sanitize(&guc->fw);
+ intel_guc_disable_interrupts(guc);
intel_guc_ct_sanitize(&guc->ct);
guc->mmio_msg = 0;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index f0b02200aa01..ab11fe731ee7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -207,21 +207,6 @@ static void guc_handle_mmio_msg(struct intel_guc *guc)
spin_unlock_irq(&guc->irq_lock);
}
-static void guc_reset_interrupts(struct intel_guc *guc)
-{
- guc->interrupts.reset(guc);
-}
-
-static void guc_enable_interrupts(struct intel_guc *guc)
-{
- guc->interrupts.enable(guc);
-}
-
-static void guc_disable_interrupts(struct intel_guc *guc)
-{
- guc->interrupts.disable(guc);
-}
-
static int guc_enable_communication(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
@@ -242,7 +227,7 @@ static int guc_enable_communication(struct intel_guc *guc)
guc_get_mmio_msg(guc);
guc_handle_mmio_msg(guc);
- guc_enable_interrupts(guc);
+ intel_guc_enable_interrupts(guc);
/* check for CT messages received before we enabled interrupts */
spin_lock_irq(>->irq_lock);
@@ -265,7 +250,7 @@ static void guc_disable_communication(struct intel_guc *guc)
*/
guc_clear_mmio_msg(guc);
- guc_disable_interrupts(guc);
+ intel_guc_disable_interrupts(guc);
intel_guc_ct_disable(&guc->ct);
@@ -463,7 +448,7 @@ static int __uc_init_hw(struct intel_uc *uc)
if (ret)
goto err_out;
- guc_reset_interrupts(guc);
+ intel_guc_reset_interrupts(guc);
/* WaEnableuKernelHeaderValidFix:skl */
/* WaEnableGuCBootHashCheckNotSet:skl,bxt,kbl */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/47] drm/i915: Track 'serial' counts for virtual engines
On Mon, Jul 12, 2021 at 11:11:48AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > From: John Harrison
> >
> > The serial number tracking of engines happens at the backend of
> > request submission and was expecting to only be given physical
> > engines. However, in GuC submission mode, the decomposition of virtual
> > to physical engines does not happen in i915. Instead, requests are
> > submitted to their virtual engine mask all the way through to the
> > hardware (i.e. to GuC). This would mean that the heart beat code
> > thinks the physical engines are idle due to the serial number not
> > incrementing.
> >
> > This patch updates the tracking to decompose virtual engines into
> > their physical constituents and tracks the request against each. This
> > is not entirely accurate as the GuC will only be issuing the request
> > to one physical engine. However, it is the best that i915 can do given
> > that it has no knowledge of the GuC's scheduling decisions.
> >
> > Signed-off-by: John Harrison
> > Signed-off-by: Matthew Brost
> Need to pull in the updated subject line and commit description from Tvrtko
> in the RFC patch set review.
>
Yep, forgot to do this. Will do in next rev.
Matt
> John.
>
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 ++
> > .../gpu/drm/i915/gt/intel_execlists_submission.c | 6 ++
> > drivers/gpu/drm/i915/gt/intel_ring_submission.c | 6 ++
> > drivers/gpu/drm/i915/gt/mock_engine.c| 6 ++
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c| 16
> > drivers/gpu/drm/i915/i915_request.c | 4 +++-
> > 6 files changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 5b91068ab277..1dc59e6c9a92 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -388,6 +388,8 @@ struct intel_engine_cs {
> > void(*park)(struct intel_engine_cs *engine);
> > void(*unpark)(struct intel_engine_cs *engine);
> > + void(*bump_serial)(struct intel_engine_cs *engine);
> > +
> > void(*set_default_submission)(struct intel_engine_cs
> > *engine);
> > const struct intel_context_ops *cops;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index bd4ced794ff9..9cfb8800a0e6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -3203,6 +3203,11 @@ static void execlists_release(struct intel_engine_cs
> > *engine)
> > lrc_fini_wa_ctx(engine);
> > }
> > +static void execlist_bump_serial(struct intel_engine_cs *engine)
> > +{
> > + engine->serial++;
> > +}
> > +
> > static void
> > logical_ring_default_vfuncs(struct intel_engine_cs *engine)
> > {
> > @@ -3212,6 +3217,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs
> > *engine)
> > engine->cops = &execlists_context_ops;
> > engine->request_alloc = execlists_request_alloc;
> > + engine->bump_serial = execlist_bump_serial;
> > engine->reset.prepare = execlists_reset_prepare;
> > engine->reset.rewind = execlists_reset_rewind;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > index 5d42a12ef3d6..e1506b280df1 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > @@ -1044,6 +1044,11 @@ static void setup_irq(struct intel_engine_cs *engine)
> > }
> > }
> > +static void ring_bump_serial(struct intel_engine_cs *engine)
> > +{
> > + engine->serial++;
> > +}
> > +
> > static void setup_common(struct intel_engine_cs *engine)
> > {
> > struct drm_i915_private *i915 = engine->i915;
> > @@ -1063,6 +1068,7 @@ static void setup_common(struct intel_engine_cs
> > *engine)
> > engine->cops = &ring_context_ops;
> > engine->request_alloc = ring_request_alloc;
> > + engine->bump_serial = ring_bump_serial;
> > /*
> > * Using a global execution timeline; the previous final breadcrumb is
> > diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
> > b/drivers/gpu/drm/i915/gt/mock_engine.c
> > index 68970398e4ef..9203c766db80 100644
> > --- a/drivers/gpu/drm/i915/gt/mock_engine.c
> > +++ b/drivers/gpu/drm/i915/gt/mock_engine.c
> > @@ -292,6 +292,11 @@ static void mock_engine_release(struct intel_engine_cs
> > *engine)
> > intel_engine_fini_retire(engine);
> > }
> > +static void mock_bump_serial(struct intel_engine_cs *engine)
> > +{
> > + engine->serial++;
> > +}
> > +
> > struct intel_engine_cs *mock_engine(struct drm_i915_private *i915,
> > const char *name,
> > int id)
> > @
Re: [Intel-gfx] [PATCH 28/47] drm/i915: Hold reference to intel_context over life of i915_request
On Mon, Jul 12, 2021 at 11:23:14AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Hold a reference to the intel_context over life of an i915_request.
> > Without this an i915_request can exist after the context has been
> > destroyed (e.g. request retired, context closed, but user space holds a
> > reference to the request from an out fence). In the case of GuC
> > submission + virtual engine, the engine that the request references is
> > also destroyed which can trigger bad pointer dref in fence ops (e.g.
> Maybe quickly explain a why this is different for GuC submission vs
> execlist? Presumably it is about only decomposing virtual engines to
> physical ones in execlist mode?
>
Yes, it because in execlists we always end up pointing to a physical
engine in the end while in GuC mode we can be pointing to dynamically
allocated virtual engine. I can update the comment.
>
> > i915_fence_get_driver_name). We could likely change
> > i915_fence_get_driver_name to avoid touching the engine but let's just
> > be safe and hold the intel_context reference.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/i915_request.c | 54 -
> > 1 file changed, 22 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index de9deb95b8b1..dec5a35c9aa2 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -126,39 +126,17 @@ static void i915_fence_release(struct dma_fence
> > *fence)
> > i915_sw_fence_fini(&rq->semaphore);
> > /*
> > -* Keep one request on each engine for reserved use under mempressure
> > -*
> > -* We do not hold a reference to the engine here and so have to be
> > -* very careful in what rq->engine we poke. The virtual engine is
> > -* referenced via the rq->context and we released that ref during
> > -* i915_request_retire(), ergo we must not dereference a virtual
> > -* engine here. Not that we would want to, as the only consumer of
> > -* the reserved engine->request_pool is the power management parking,
> > -* which must-not-fail, and that is only run on the physical engines.
> > -*
> > -* Since the request must have been executed to be have completed,
> > -* we know that it will have been processed by the HW and will
> > -* not be unsubmitted again, so rq->engine and rq->execution_mask
> > -* at this point is stable. rq->execution_mask will be a single
> > -* bit if the last and _only_ engine it could execution on was a
> > -* physical engine, if it's multiple bits then it started on and
> > -* could still be on a virtual engine. Thus if the mask is not a
> > -* power-of-two we assume that rq->engine may still be a virtual
> > -* engine and so a dangling invalid pointer that we cannot dereference
> > -*
> > -* For example, consider the flow of a bonded request through a virtual
> > -* engine. The request is created with a wide engine mask (all engines
> > -* that we might execute on). On processing the bond, the request mask
> > -* is reduced to one or more engines. If the request is subsequently
> > -* bound to a single engine, it will then be constrained to only
> > -* execute on that engine and never returned to the virtual engine
> > -* after timeslicing away, see __unwind_incomplete_requests(). Thus we
> > -* know that if the rq->execution_mask is a single bit, rq->engine
> > -* can be a physical engine with the exact corresponding mask.
> > +* Keep one request on each engine for reserved use under mempressure,
> > +* do not use with virtual engines as this really is only needed for
> > +* kernel contexts.
> > */
> > - if (is_power_of_2(rq->execution_mask) &&
> > - !cmpxchg(&rq->engine->request_pool, NULL, rq))
> > + if (!intel_engine_is_virtual(rq->engine) &&
> > + !cmpxchg(&rq->engine->request_pool, NULL, rq)) {
> > + intel_context_put(rq->context);
> > return;
> > + }
> > +
> > + intel_context_put(rq->context);
> The put is actually unconditional? So it could be moved before the if?
>
Yep, I think so.
Matt
> John.
>
> > kmem_cache_free(global.slab_requests, rq);
> > }
> > @@ -977,7 +955,18 @@ __i915_request_create(struct intel_context *ce, gfp_t
> > gfp)
> > }
> > }
> > - rq->context = ce;
> > + /*
> > +* Hold a reference to the intel_context over life of an i915_request.
> > +* Without this an i915_request can exist after the context has been
> > +* destroyed (e.g. request retired, context closed, but user space holds
> > +* a reference to the request from an out fence). In the case of GuC
> > +* submission + virtual engine, the engine that the request references
> > +* is also destroyed which can trigger bad pointer dref in fence ops
> > +* (e.g
[Intel-gfx] [PATCH v4 15/18] drm/etnaviv: Don't break exclusive fence ordering
There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore them.
A better fix would be to us a dma_fence_chain or _array like e.g.
amdgpu now uses, but it probably makes sense to lift this into
dma-resv.c code as a proper concept, so that drivers don't have to
hack up their own solution each on their own. Hence go with the simple
fix for now.
Another option is the fence import ioctl from Jason:
https://lore.kernel.org/dri-devel/20210610210925.642582-7-ja...@jlekstrand.net/
v2: Improve commit message per Lucas' suggestion.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 5b97ce1299ad..07454db4b150 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -178,18 +178,20 @@ static int submit_fence_sync(struct etnaviv_gem_submit
*submit)
for (i = 0; i < submit->nr_bos; i++) {
struct etnaviv_gem_submit_bo *bo = &submit->bos[i];
struct dma_resv *robj = bo->obj->base.resv;
+ bool write = bo->flags & ETNA_SUBMIT_BO_WRITE;
- if (!(bo->flags & ETNA_SUBMIT_BO_WRITE)) {
+ if (!(write)) {
ret = dma_resv_reserve_shared(robj, 1);
if (ret)
return ret;
}
- if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT)
+ /* exclusive fences must be ordered */
+ if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT && !write)
continue;
ret = drm_sched_job_await_implicit(&submit->sched_job,
&bo->obj->base,
- bo->flags &
ETNA_SUBMIT_BO_WRITE);
+ write);
if (ret)
return ret;
}
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 16/18] drm/i915: delete exclude argument from i915_sw_fence_await_reservation
No longer used, the last user disappeared with
commit d07f0e59b2c762584478920cd2d11fba2980a94a
Author: Chris Wilson
Date: Fri Oct 28 13:58:44 2016 +0100
drm/i915: Move GEM activity tracking into a common struct reservation_object
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: "Thomas Hellström"
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_clflush.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_sw_fence.c | 6 +-
drivers/gpu/drm/i915/i915_sw_fence.h | 1 -
5 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 98e0f4ed7e4a..678c7839034e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9,7 +9,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
*/
if (intel_crtc_needs_modeset(crtc_state)) {
ret =
i915_sw_fence_await_reservation(&state->commit_ready,
-
old_obj->base.resv, NULL,
+
old_obj->base.resv,
false, 0,
GFP_KERNEL);
if (ret < 0)
@@ -11153,7 +11153,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
struct dma_fence *fence;
ret = i915_sw_fence_await_reservation(&state->commit_ready,
- obj->base.resv, NULL,
+ obj->base.resv,
false,
i915_fence_timeout(dev_priv),
GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index daf9284ef1f5..93439d2c7a58 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -106,7 +106,7 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object
*obj,
clflush = clflush_work_create(obj);
if (clflush) {
i915_sw_fence_await_reservation(&clflush->base.chain,
- obj->base.resv, NULL, true,
+ obj->base.resv, true,
i915_fence_timeout(to_i915(obj->base.dev)),
I915_FENCE_GFP);
dma_resv_add_excl_fence(obj->base.resv, &clflush->base.dma);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b95c8927d465..b4a77eba8631 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2087,7 +2087,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
/* Wait for all writes (and relocs) into the batch to complete */
err = i915_sw_fence_await_reservation(&pw->base.chain,
- pw->batch->resv, NULL, false,
+ pw->batch->resv, false,
0, I915_FENCE_GFP);
if (err < 0)
goto err_commit;
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index c589a681da77..91711a46b1c7 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -567,7 +567,6 @@ int __i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
int i915_sw_fence_await_reservation(struct i915_sw_fence *fence,
struct dma_resv *resv,
- const struct dma_fence_ops *exclude,
bool write,
unsigned long timeout,
gfp_t gfp)
@@ -587,9 +586,6 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence
*fence,
return ret;
for (i = 0; i < count; i++) {
- if (shared[i]->ops == exclude)
- continue;
-
pending = i915_sw_fence_await_dma_fence(fence,
shared[i],
timeout,
@@ -609,7 +605,7 @@ int i915_sw_fence_await_reservation(struct i915_sw_fence
*fence,
excl = dma_resv_get_excl_unlocked(resv);
}
- if (ret >= 0 && excl && excl->ops
[Intel-gfx] [PATCH v4 18/18] dma-resv: Give the docs a do-over
Specifically document the new/clarified rules around how the shared
fences do not have any ordering requirements against the exclusive
fence.
But also document all the things a bit better, given how central
struct dma_resv to dynamic buffer management the docs have been very
inadequat.
- Lots more links to other pieces of the puzzle. Unfortunately
ttm_buffer_object has no docs, so no links :-(
- Explain/complain a bit about dma_resv_locking_ctx(). I still don't
like that one, but fixing the ttm call chains is going to be
horrible. Plus we want to plug in real slowpath locking when we do
that anyway.
- Main part of the patch is some actual docs for struct dma_resv.
Overall I think we still have a lot of bad naming in this area (e.g.
dma_resv.fence is singular, but contains the multiple shared fences),
but I think that's more indicative of how the semantics and rules are
just not great.
Another thing that's real awkard is how chaining exclusive fences
right now means direct dma_resv.exclusive_fence pointer access with an
rcu_assign_pointer. Not so great either.
v2:
- Fix a pile of typos (Matt, Jason)
- Hammer it in that breaking the rules leads to use-after-free issues
around dma-buf sharing (Christian)
Reviewed-by: Christian König
Cc: Jason Ekstrand
Cc: Matthew Auld
Reviewed-by: Matthew Auld
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-resv.c | 24 ++---
include/linux/dma-buf.h| 7 +++
include/linux/dma-resv.h | 104 +++--
3 files changed, 124 insertions(+), 11 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index e744fd87c63c..84fbe60629e3 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -48,6 +48,8 @@
* write operations) or N shared fences (read operations). The RCU
* mechanism is used to protect read access to fences from locked
* write-side updates.
+ *
+ * See struct dma_resv for more details.
*/
DEFINE_WD_CLASS(reservation_ww_class);
@@ -137,7 +139,11 @@ EXPORT_SYMBOL(dma_resv_fini);
* @num_fences: number of fences we want to add
*
* Should be called before dma_resv_add_shared_fence(). Must
- * be called with obj->lock held.
+ * be called with @obj locked through dma_resv_lock().
+ *
+ * Note that the preallocated slots need to be re-reserved if @obj is unlocked
+ * at any time before calling dma_resv_add_shared_fence(). This is validated
+ * when CONFIG_DEBUG_MUTEXES is enabled.
*
* RETURNS
* Zero for success, or -errno
@@ -234,8 +240,10 @@ EXPORT_SYMBOL(dma_resv_reset_shared_max);
* @obj: the reservation object
* @fence: the shared fence to add
*
- * Add a fence to a shared slot, obj->lock must be held, and
+ * Add a fence to a shared slot, @obj must be locked with dma_resv_lock(), and
* dma_resv_reserve_shared() has been called.
+ *
+ * See also &dma_resv.fence for a discussion of the semantics.
*/
void dma_resv_add_shared_fence(struct dma_resv *obj, struct dma_fence *fence)
{
@@ -278,9 +286,11 @@ EXPORT_SYMBOL(dma_resv_add_shared_fence);
/**
* dma_resv_add_excl_fence - Add an exclusive fence.
* @obj: the reservation object
- * @fence: the shared fence to add
+ * @fence: the exclusive fence to add
*
- * Add a fence to the exclusive slot. The obj->lock must be held.
+ * Add a fence to the exclusive slot. @obj must be locked with dma_resv_lock().
+ * Note that this function replaces all fences attached to @obj, see also
+ * &dma_resv.fence_excl for a discussion of the semantics.
*/
void dma_resv_add_excl_fence(struct dma_resv *obj, struct dma_fence *fence)
{
@@ -609,9 +619,11 @@ static inline int dma_resv_test_signaled_single(struct
dma_fence *passed_fence)
* fence
*
* Callers are not required to hold specific locks, but maybe hold
- * dma_resv_lock() already
+ * dma_resv_lock() already.
+ *
* RETURNS
- * true if all fences signaled, else false
+ *
+ * True if all fences signaled, else false.
*/
bool dma_resv_test_signaled(struct dma_resv *obj, bool test_all)
{
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 2b814fde0d11..8cc0c55877a6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -420,6 +420,13 @@ struct dma_buf {
* - Dynamic importers should set fences for any access that they can't
* disable immediately from their &dma_buf_attach_ops.move_notify
* callback.
+*
+* IMPORTANT:
+*
+* All drivers must obey the struct dma_resv rules, specifically the
+* rules for updating fences, see &dma_resv.fence_excl and
+* &dma_resv.fence. If these dependency rules are broken access tracking
+* can be lost resulting in use after free issues.
*/
struct dma_resv *resv;
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index e1ca2080a1ff..9100dd3dc21f 1
[Intel-gfx] [PATCH v4 17/18] drm/i915: Don't break exclusive fence ordering
There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore them.
A better fix would be to us a dma_fence_chain or _array like e.g.
amdgpu now uses, but it probably makes sense to lift this into
dma-resv.c code as a proper concept, so that drivers don't have to
hack up their own solution each on their own. Hence go with the simple
fix for now.
Another option is the fence import ioctl from Jason:
https://lore.kernel.org/dri-devel/20210610210925.642582-7-ja...@jlekstrand.net/
v2: Improve commit message per Lucas' suggestion.
Cc: Lucas Stach
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: "Thomas Hellström"
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b4a77eba8631..b3d675987493 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1767,6 +1767,7 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
struct i915_vma *vma = ev->vma;
unsigned int flags = ev->flags;
struct drm_i915_gem_object *obj = vma->obj;
+ bool async, write;
assert_vma_held(vma);
@@ -1798,7 +1799,10 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
flags &= ~EXEC_OBJECT_ASYNC;
}
- if (err == 0 && !(flags & EXEC_OBJECT_ASYNC)) {
+ async = flags & EXEC_OBJECT_ASYNC;
+ write = flags & EXEC_OBJECT_WRITE;
+
+ if (err == 0 && (!async || write)) {
err = i915_request_await_object
(eb->request, obj, flags & EXEC_OBJECT_WRITE);
}
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 13/18] drm/sched: Check locking in drm_sched_job_await_implicit
You really need to hold the reservation here or all kinds of funny
things can happen between grabbing the dependencies and inserting the
new fences.
Signed-off-by: Daniel Vetter
Cc: "Christian König"
Cc: Daniel Vetter
Cc: Luben Tuikov
Cc: Andrey Grodzovsky
Cc: Alex Deucher
Cc: Jack Zhang
---
drivers/gpu/drm/scheduler/sched_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index fd52db906b90..6fa6ccd30d2a 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -714,6 +714,8 @@ int drm_sched_job_await_implicit(struct drm_sched_job *job,
struct dma_fence **fences;
unsigned int i, fence_count;
+ dma_resv_assert_held(obj->resv);
+
if (!write) {
struct dma_fence *fence = dma_resv_get_excl_unlocked(obj->resv);
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 14/18] drm/msm: Don't break exclusive fence ordering
There's only one exclusive slot, and we must not break the ordering. Adding a new exclusive fence drops all previous fences from the dma_resv. To avoid violating the signalling order we err on the side of over-synchronizing by waiting for the existing fences, even if userspace asked us to ignore them. A better fix would be to us a dma_fence_chain or _array like e.g. amdgpu now uses, but - msm has a synchronous dma_fence_wait for anything from another context, so doesn't seem to care much, - and it probably makes sense to lift this into dma-resv.c code as a proper concept, so that drivers don't have to hack up their own solution each on their own. v2: Improve commit message per Lucas' suggestion. Cc: Lucas Stach Signed-off-by: Daniel Vetter Cc: Rob Clark Cc: Sean Paul Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org --- drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index b71da71a3dd8..edd0051d849f 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -306,7 +306,8 @@ static int submit_fence_sync(struct msm_gem_submit *submit, bool no_implicit) return ret; } - if (no_implicit) + /* exclusive fences must be ordered */ + if (no_implicit && !write) continue; ret = msm_gem_sync_object(&msm_obj->base, submit->ring->fctx, -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 12/18] drm/sched: Don't store self-dependencies
This is essentially part of drm_sched_dependency_optimized(), which
only amdgpu seems to make use of. Use it a bit more.
This would mean that as-is amdgpu can't use the dependency helpers, at
least not with the current approach amdgpu has for deciding whether a
vm_flush is needed. Since amdgpu also has very special rules around
implicit fencing it can't use those helpers either, and adding a
drm_sched_job_await_fence_always or similar for amdgpu wouldn't be too
onerous. That way the special case handling for amdgpu sticks even
more out and we have higher chances that reviewers that go across all
drivers wont miss it.
Reviewed-by: Lucas Stach
Signed-off-by: Daniel Vetter
Cc: "Christian König"
Cc: Daniel Vetter
Cc: Luben Tuikov
Cc: Andrey Grodzovsky
Cc: Alex Deucher
Cc: Jack Zhang
---
drivers/gpu/drm/scheduler/sched_main.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 84c30badb78e..fd52db906b90 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -660,6 +660,13 @@ int drm_sched_job_await_fence(struct drm_sched_job *job,
if (!fence)
return 0;
+ /* if it's a fence from us it's guaranteed to be earlier */
+ if (fence->context == job->entity->fence_context ||
+ fence->context == job->entity->fence_context + 1) {
+ dma_fence_put(fence);
+ return 0;
+ }
+
/* Deduplicate if we already depend on a fence from the same context.
* This lets the size of the array of deps scale with the number of
* engines involved, rather than the number of BOs.
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 10/18] drm/etnaviv: Use scheduler dependency handling
We need to pull the drm_sched_job_init much earlier, but that's very
minor surgery.
v2: Actually fix up cleanup paths by calling drm_sched_job_init, which
I wanted to to in the previous round (and did, for all other drivers).
Spotted by Lucas.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Sumit Semwal
Cc: "Christian König"
Cc: etna...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/gpu/drm/etnaviv/etnaviv_gem.h| 5 +-
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 58 +-
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 63 +---
drivers/gpu/drm/etnaviv/etnaviv_sched.h | 3 +-
4 files changed, 35 insertions(+), 94 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
index 98e60df882b6..63688e6e4580 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
@@ -80,9 +80,6 @@ struct etnaviv_gem_submit_bo {
u64 va;
struct etnaviv_gem_object *obj;
struct etnaviv_vram_mapping *mapping;
- struct dma_fence *excl;
- unsigned int nr_shared;
- struct dma_fence **shared;
};
/* Created per submit-ioctl, to track bo's and cmdstream bufs, etc,
@@ -95,7 +92,7 @@ struct etnaviv_gem_submit {
struct etnaviv_file_private *ctx;
struct etnaviv_gpu *gpu;
struct etnaviv_iommu_context *mmu_context, *prev_mmu_context;
- struct dma_fence *out_fence, *in_fence;
+ struct dma_fence *out_fence;
int out_fence_id;
struct list_head node; /* GPU active submit list */
struct etnaviv_cmdbuf cmdbuf;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 4dd7d9d541c0..5b97ce1299ad 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -188,16 +188,10 @@ static int submit_fence_sync(struct etnaviv_gem_submit
*submit)
if (submit->flags & ETNA_SUBMIT_NO_IMPLICIT)
continue;
- if (bo->flags & ETNA_SUBMIT_BO_WRITE) {
- ret = dma_resv_get_fences(robj, &bo->excl,
- &bo->nr_shared,
- &bo->shared);
- if (ret)
- return ret;
- } else {
- bo->excl = dma_resv_get_excl_unlocked(robj);
- }
-
+ ret = drm_sched_job_await_implicit(&submit->sched_job,
&bo->obj->base,
+ bo->flags &
ETNA_SUBMIT_BO_WRITE);
+ if (ret)
+ return ret;
}
return ret;
@@ -403,8 +397,6 @@ static void submit_cleanup(struct kref *kref)
wake_up_all(&submit->gpu->fence_event);
- if (submit->in_fence)
- dma_fence_put(submit->in_fence);
if (submit->out_fence) {
/* first remove from IDR, so fence can not be found anymore */
mutex_lock(&submit->gpu->fence_lock);
@@ -529,7 +521,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
ret = etnaviv_cmdbuf_init(priv->cmdbuf_suballoc, &submit->cmdbuf,
ALIGN(args->stream_size, 8) + 8);
if (ret)
- goto err_submit_objects;
+ goto err_submit_put;
submit->ctx = file->driver_priv;
etnaviv_iommu_context_get(submit->ctx->mmu);
@@ -537,51 +529,61 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
submit->exec_state = args->exec_state;
submit->flags = args->flags;
+ ret = drm_sched_job_init(&submit->sched_job,
+&ctx->sched_entity[args->pipe],
+submit->ctx);
+ if (ret)
+ goto err_submit_put;
+
ret = submit_lookup_objects(submit, file, bos, args->nr_bos);
if (ret)
- goto err_submit_objects;
+ goto err_submit_job;
if ((priv->mmu_global->version != ETNAVIV_IOMMU_V2) &&
!etnaviv_cmd_validate_one(gpu, stream, args->stream_size / 4,
relocs, args->nr_relocs)) {
ret = -EINVAL;
- goto err_submit_objects;
+ goto err_submit_job;
}
if (args->flags & ETNA_SUBMIT_FENCE_FD_IN) {
- submit->in_fence = sync_file_get_fence(args->fence_fd);
- if (!submit->in_fence) {
+ struct dma_fence *in_fence =
sync_file_get_fence(args->fence_fd);
+ if (!in_fence) {
ret = -EINVAL;
- goto err_submit_objects;
+ goto err_submit_job;
}
+
+ ret = dr
[Intel-gfx] [PATCH v4 11/18] drm/gem: Delete gem array fencing helpers
Integrated into the scheduler now and all users converted over.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/gpu/drm/drm_gem.c | 96 ---
include/drm/drm_gem.h | 5 --
2 files changed, 101 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 68deb1de8235..24d49a2636e0 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1294,99 +1294,3 @@ drm_gem_unlock_reservations(struct drm_gem_object
**objs, int count,
ww_acquire_fini(acquire_ctx);
}
EXPORT_SYMBOL(drm_gem_unlock_reservations);
-
-/**
- * drm_gem_fence_array_add - Adds the fence to an array of fences to be
- * waited on, deduplicating fences from the same context.
- *
- * @fence_array: array of dma_fence * for the job to block on.
- * @fence: the dma_fence to add to the list of dependencies.
- *
- * This functions consumes the reference for @fence both on success and error
- * cases.
- *
- * Returns:
- * 0 on success, or an error on failing to expand the array.
- */
-int drm_gem_fence_array_add(struct xarray *fence_array,
- struct dma_fence *fence)
-{
- struct dma_fence *entry;
- unsigned long index;
- u32 id = 0;
- int ret;
-
- if (!fence)
- return 0;
-
- /* Deduplicate if we already depend on a fence from the same context.
-* This lets the size of the array of deps scale with the number of
-* engines involved, rather than the number of BOs.
-*/
- xa_for_each(fence_array, index, entry) {
- if (entry->context != fence->context)
- continue;
-
- if (dma_fence_is_later(fence, entry)) {
- dma_fence_put(entry);
- xa_store(fence_array, index, fence, GFP_KERNEL);
- } else {
- dma_fence_put(fence);
- }
- return 0;
- }
-
- ret = xa_alloc(fence_array, &id, fence, xa_limit_32b, GFP_KERNEL);
- if (ret != 0)
- dma_fence_put(fence);
-
- return ret;
-}
-EXPORT_SYMBOL(drm_gem_fence_array_add);
-
-/**
- * drm_gem_fence_array_add_implicit - Adds the implicit dependencies tracked
- * in the GEM object's reservation object to an array of dma_fences for use in
- * scheduling a rendering job.
- *
- * This should be called after drm_gem_lock_reservations() on your array of
- * GEM objects used in the job but before updating the reservations with your
- * own fences.
- *
- * @fence_array: array of dma_fence * for the job to block on.
- * @obj: the gem object to add new dependencies from.
- * @write: whether the job might write the object (so we need to depend on
- * shared fences in the reservation object).
- */
-int drm_gem_fence_array_add_implicit(struct xarray *fence_array,
-struct drm_gem_object *obj,
-bool write)
-{
- int ret;
- struct dma_fence **fences;
- unsigned int i, fence_count;
-
- if (!write) {
- struct dma_fence *fence =
- dma_resv_get_excl_unlocked(obj->resv);
-
- return drm_gem_fence_array_add(fence_array, fence);
- }
-
- ret = dma_resv_get_fences(obj->resv, NULL,
- &fence_count, &fences);
- if (ret || !fence_count)
- return ret;
-
- for (i = 0; i < fence_count; i++) {
- ret = drm_gem_fence_array_add(fence_array, fences[i]);
- if (ret)
- break;
- }
-
- for (; i < fence_count; i++)
- dma_fence_put(fences[i]);
- kfree(fences);
- return ret;
-}
-EXPORT_SYMBOL(drm_gem_fence_array_add_implicit);
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 240049566592..6d5e33b89074 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -409,11 +409,6 @@ int drm_gem_lock_reservations(struct drm_gem_object
**objs, int count,
struct ww_acquire_ctx *acquire_ctx);
void drm_gem_unlock_reservations(struct drm_gem_object **objs, int count,
struct ww_acquire_ctx *acquire_ctx);
-int drm_gem_fence_array_add(struct xarray *fence_array,
- struct dma_fence *fence);
-int drm_gem_fence_array_add_implicit(struct xarray *fence_array,
-struct drm_gem_object *obj,
-bool write);
int drm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
u32 handle, u64 *offset);
--
2.32.0
___
Intel-gfx mailing list
Int
[Intel-gfx] [PATCH v4 09/18] drm/v3d: Use scheduler dependency handling
With the prep work out of the way this isn't tricky anymore.
Aside: The chaining of the various jobs is a bit awkward, with the
possibility of failure in bad places. I think with the
drm_sched_job_init/arm split and maybe preloading the
job->dependencies xarray this should be fixable.
Cc: Melissa Wen
Signed-off-by: Daniel Vetter
Cc: Cc: Emma Anholt
---
drivers/gpu/drm/v3d/v3d_drv.h | 5 -
drivers/gpu/drm/v3d/v3d_gem.c | 25 -
drivers/gpu/drm/v3d/v3d_sched.c | 29 +
3 files changed, 9 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 1d870261eaac..f80f4ff1f7aa 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -192,11 +192,6 @@ struct v3d_job {
struct drm_gem_object **bo;
u32 bo_count;
- /* Array of struct dma_fence * to block on before submitting this job.
-*/
- struct xarray deps;
- unsigned long last_dep;
-
/* v3d fence to be signaled by IRQ handler when the job is complete. */
struct dma_fence *irq_fence;
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 5eccd3658938..42b07ffbea5e 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -257,8 +257,8 @@ v3d_lock_bo_reservations(struct v3d_job *job,
return ret;
for (i = 0; i < job->bo_count; i++) {
- ret = drm_gem_fence_array_add_implicit(&job->deps,
- job->bo[i], true);
+ ret = drm_sched_job_await_implicit(&job->base,
+ job->bo[i], true);
if (ret) {
drm_gem_unlock_reservations(job->bo, job->bo_count,
acquire_ctx);
@@ -354,8 +354,6 @@ static void
v3d_job_free(struct kref *ref)
{
struct v3d_job *job = container_of(ref, struct v3d_job, refcount);
- unsigned long index;
- struct dma_fence *fence;
int i;
for (i = 0; i < job->bo_count; i++) {
@@ -364,11 +362,6 @@ v3d_job_free(struct kref *ref)
}
kvfree(job->bo);
- xa_for_each(&job->deps, index, fence) {
- dma_fence_put(fence);
- }
- xa_destroy(&job->deps);
-
dma_fence_put(job->irq_fence);
dma_fence_put(job->done_fence);
@@ -452,7 +445,6 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
*file_priv,
if (ret < 0)
return ret;
- xa_init_flags(&job->deps, XA_FLAGS_ALLOC);
ret = drm_sched_job_init(&job->base, &v3d_priv->sched_entity[queue],
v3d_priv);
if (ret)
@@ -462,7 +454,7 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
*file_priv,
if (ret == -EINVAL)
goto fail_job;
- ret = drm_gem_fence_array_add(&job->deps, in_fence);
+ ret = drm_sched_job_await_fence(&job->base, in_fence);
if (ret)
goto fail_job;
@@ -472,7 +464,6 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
*file_priv,
fail_job:
drm_sched_job_cleanup(&job->base);
fail:
- xa_destroy(&job->deps);
pm_runtime_put_autosuspend(v3d->drm.dev);
return ret;
}
@@ -619,8 +610,8 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
if (bin) {
v3d_push_job(&bin->base);
- ret = drm_gem_fence_array_add(&render->base.deps,
-
dma_fence_get(bin->base.done_fence));
+ ret = drm_sched_job_await_fence(&render->base.base,
+
dma_fence_get(bin->base.done_fence));
if (ret)
goto fail_unreserve;
}
@@ -630,7 +621,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
if (clean_job) {
struct dma_fence *render_fence =
dma_fence_get(render->base.done_fence);
- ret = drm_gem_fence_array_add(&clean_job->deps, render_fence);
+ ret = drm_sched_job_await_fence(&clean_job->base, render_fence);
if (ret)
goto fail_unreserve;
v3d_push_job(clean_job);
@@ -820,8 +811,8 @@ v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
mutex_lock(&v3d->sched_lock);
v3d_push_job(&job->base);
- ret = drm_gem_fence_array_add(&clean_job->deps,
- dma_fence_get(job->base.done_fence));
+ ret = drm_sched_job_await_fence(&clean_job->base,
+ dma_fence_get(job->base.done_fence));
if (ret)
goto fail_unreserve;
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 3f352d73af9c..f0de584f452c 100644
--- a/drivers/gpu/drm
[Intel-gfx] [PATCH v4 08/18] drm/v3d: Move drm_sched_job_init to v3d_job_init
Prep work for using the scheduler dependency handling. We need to call
drm_sched_job_init earlier so we can use the new drm_sched_job_await*
functions for dependency handling here.
v2: Slightly better commit message and rebase to include the
drm_sched_job_arm() call (Emma).
v3: Cleanup jobs under construction correctly (Emma)
Cc: Melissa Wen
Signed-off-by: Daniel Vetter
Cc: Emma Anholt
---
drivers/gpu/drm/v3d/v3d_drv.h | 1 +
drivers/gpu/drm/v3d/v3d_gem.c | 88 ++---
drivers/gpu/drm/v3d/v3d_sched.c | 15 +++---
3 files changed, 44 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 8a390738d65b..1d870261eaac 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -332,6 +332,7 @@ int v3d_submit_csd_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+void v3d_job_cleanup(struct v3d_job *job);
void v3d_job_put(struct v3d_job *job);
void v3d_reset(struct v3d_dev *v3d);
void v3d_invalidate_caches(struct v3d_dev *v3d);
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 69ac20e11b09..5eccd3658938 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -392,6 +392,12 @@ v3d_render_job_free(struct kref *ref)
v3d_job_free(ref);
}
+void v3d_job_cleanup(struct v3d_job *job)
+{
+ drm_sched_job_cleanup(&job->base);
+ v3d_job_put(job);
+}
+
void v3d_job_put(struct v3d_job *job)
{
kref_put(&job->refcount, job->free);
@@ -433,9 +439,10 @@ v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
static int
v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
struct v3d_job *job, void (*free)(struct kref *ref),
-u32 in_sync)
+u32 in_sync, enum v3d_queue queue)
{
struct dma_fence *in_fence = NULL;
+ struct v3d_file_priv *v3d_priv = file_priv->driver_priv;
int ret;
job->v3d = v3d;
@@ -446,35 +453,33 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
*file_priv,
return ret;
xa_init_flags(&job->deps, XA_FLAGS_ALLOC);
+ ret = drm_sched_job_init(&job->base, &v3d_priv->sched_entity[queue],
+v3d_priv);
+ if (ret)
+ goto fail;
ret = drm_syncobj_find_fence(file_priv, in_sync, 0, 0, &in_fence);
if (ret == -EINVAL)
- goto fail;
+ goto fail_job;
ret = drm_gem_fence_array_add(&job->deps, in_fence);
if (ret)
- goto fail;
+ goto fail_job;
kref_init(&job->refcount);
return 0;
+fail_job:
+ drm_sched_job_cleanup(&job->base);
fail:
xa_destroy(&job->deps);
pm_runtime_put_autosuspend(v3d->drm.dev);
return ret;
}
-static int
-v3d_push_job(struct v3d_file_priv *v3d_priv,
-struct v3d_job *job, enum v3d_queue queue)
+static void
+v3d_push_job(struct v3d_job *job)
{
- int ret;
-
- ret = drm_sched_job_init(&job->base, &v3d_priv->sched_entity[queue],
-v3d_priv);
- if (ret)
- return ret;
-
drm_sched_job_arm(&job->base);
job->done_fence = dma_fence_get(&job->base.s_fence->finished);
@@ -483,8 +488,6 @@ v3d_push_job(struct v3d_file_priv *v3d_priv,
kref_get(&job->refcount);
drm_sched_entity_push_job(&job->base);
-
- return 0;
}
static void
@@ -530,7 +533,6 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct v3d_dev *v3d = to_v3d_dev(dev);
- struct v3d_file_priv *v3d_priv = file_priv->driver_priv;
struct drm_v3d_submit_cl *args = data;
struct v3d_bin_job *bin = NULL;
struct v3d_render_job *render;
@@ -556,7 +558,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
INIT_LIST_HEAD(&render->unref_list);
ret = v3d_job_init(v3d, file_priv, &render->base,
- v3d_render_job_free, args->in_sync_rcl);
+ v3d_render_job_free, args->in_sync_rcl, V3D_RENDER);
if (ret) {
kfree(render);
return ret;
@@ -570,7 +572,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
}
ret = v3d_job_init(v3d, file_priv, &bin->base,
- v3d_job_free, args->in_sync_bcl);
+ v3d_job_free, args->in_sync_bcl, V3D_BIN);
if (ret) {
v3d_job_put(&render->base);
kfree(bin);
@@ -592,7 +594,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
goto fail;
}
- ret = v3d_
[Intel-gfx] [PATCH v4 07/18] drm/lima: use scheduler dependency tracking
Nothing special going on here.
Aside reviewing the code, it seems like drm_sched_job_arm() should be
moved into lima_sched_context_queue_task and put under some mutex
together with drm_sched_push_job(). See the kerneldoc for
drm_sched_push_job().
Signed-off-by: Daniel Vetter
Cc: Qiang Yu
Cc: Sumit Semwal
Cc: "Christian König"
Cc: l...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/gpu/drm/lima/lima_gem.c | 4 ++--
drivers/gpu/drm/lima/lima_sched.c | 21 -
drivers/gpu/drm/lima/lima_sched.h | 3 ---
3 files changed, 2 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index c528f40981bb..e54a88d5037a 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -267,7 +267,7 @@ static int lima_gem_sync_bo(struct lima_sched_task *task,
struct lima_bo *bo,
if (explicit)
return 0;
- return drm_gem_fence_array_add_implicit(&task->deps, &bo->base.base,
write);
+ return drm_sched_job_await_implicit(&task->base, &bo->base.base, write);
}
static int lima_gem_add_deps(struct drm_file *file, struct lima_submit *submit)
@@ -285,7 +285,7 @@ static int lima_gem_add_deps(struct drm_file *file, struct
lima_submit *submit)
if (err)
return err;
- err = drm_gem_fence_array_add(&submit->task->deps, fence);
+ err = drm_sched_job_await_fence(&submit->task->base, fence);
if (err) {
dma_fence_put(fence);
return err;
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index e968b5a8f0b0..99d5f6f1a882 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -134,24 +134,15 @@ int lima_sched_task_init(struct lima_sched_task *task,
task->num_bos = num_bos;
task->vm = lima_vm_get(vm);
- xa_init_flags(&task->deps, XA_FLAGS_ALLOC);
-
return 0;
}
void lima_sched_task_fini(struct lima_sched_task *task)
{
- struct dma_fence *fence;
- unsigned long index;
int i;
drm_sched_job_cleanup(&task->base);
- xa_for_each(&task->deps, index, fence) {
- dma_fence_put(fence);
- }
- xa_destroy(&task->deps);
-
if (task->bos) {
for (i = 0; i < task->num_bos; i++)
drm_gem_object_put(&task->bos[i]->base.base);
@@ -186,17 +177,6 @@ struct dma_fence *lima_sched_context_queue_task(struct
lima_sched_task *task)
return fence;
}
-static struct dma_fence *lima_sched_dependency(struct drm_sched_job *job,
- struct drm_sched_entity *entity)
-{
- struct lima_sched_task *task = to_lima_task(job);
-
- if (!xa_empty(&task->deps))
- return xa_erase(&task->deps, task->last_dep++);
-
- return NULL;
-}
-
static int lima_pm_busy(struct lima_device *ldev)
{
int ret;
@@ -472,7 +452,6 @@ static void lima_sched_free_job(struct drm_sched_job *job)
}
static const struct drm_sched_backend_ops lima_sched_ops = {
- .dependency = lima_sched_dependency,
.run_job = lima_sched_run_job,
.timedout_job = lima_sched_timedout_job,
.free_job = lima_sched_free_job,
diff --git a/drivers/gpu/drm/lima/lima_sched.h
b/drivers/gpu/drm/lima/lima_sched.h
index ac70006b0e26..6a11764d87b3 100644
--- a/drivers/gpu/drm/lima/lima_sched.h
+++ b/drivers/gpu/drm/lima/lima_sched.h
@@ -23,9 +23,6 @@ struct lima_sched_task {
struct lima_vm *vm;
void *frame;
- struct xarray deps;
- unsigned long last_dep;
-
struct lima_bo **bos;
int num_bos;
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 04/18] drm/sched: drop entity parameter from drm_sched_push_job
Originally a job was only bound to the queue when we pushed this, but
now that's done in drm_sched_job_init, making that parameter entirely
redundant.
Remove it.
The same applies to the context parameter in
lima_sched_context_queue_task, simplify that too.
Reviewed-by: Steven Price (v1)
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Emma Anholt
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Alex Deucher
Cc: Nirmoy Das
Cc: Dave Airlie
Cc: Chen Li
Cc: Lee Jones
Cc: Deepak R Varma
Cc: Kevin Wang
Cc: Luben Tuikov
Cc: "Marek Olšák"
Cc: Maarten Lankhorst
Cc: Andrey Grodzovsky
Cc: Dennis Li
Cc: Boris Brezillon
Cc: etna...@lists.freedesktop.org
Cc: l...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 +-
drivers/gpu/drm/lima/lima_gem.c | 3 +--
drivers/gpu/drm/lima/lima_sched.c| 5 ++---
drivers/gpu/drm/lima/lima_sched.h| 3 +--
drivers/gpu/drm/panfrost/panfrost_job.c | 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 6 ++
drivers/gpu/drm/v3d/v3d_gem.c| 2 +-
include/drm/gpu_scheduler.h | 3 +--
10 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index a4ec092af9a7..18f63567fb69 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1267,7 +1267,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
trace_amdgpu_cs_ioctl(job);
amdgpu_vm_bo_trace_cs(&fpriv->vm, &p->ticket);
- drm_sched_entity_push_job(&job->base, entity);
+ drm_sched_entity_push_job(&job->base);
amdgpu_vm_move_to_lru_tail(p->adev, &fpriv->vm);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 5ddb955d2315..b86099c1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -174,7 +174,7 @@ int amdgpu_job_submit(struct amdgpu_job *job, struct
drm_sched_entity *entity,
*f = dma_fence_get(&job->base.s_fence->finished);
amdgpu_job_free_resources(job);
- drm_sched_entity_push_job(&job->base, entity);
+ drm_sched_entity_push_job(&job->base);
return 0;
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 05f412204118..180bb633d5c5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -178,7 +178,7 @@ int etnaviv_sched_push_job(struct drm_sched_entity
*sched_entity,
/* the scheduler holds on to the job now */
kref_get(&submit->refcount);
- drm_sched_entity_push_job(&submit->sched_job, sched_entity);
+ drm_sched_entity_push_job(&submit->sched_job);
out_unlock:
mutex_unlock(&submit->gpu->fence_lock);
diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index de62966243cd..c528f40981bb 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -359,8 +359,7 @@ int lima_gem_submit(struct drm_file *file, struct
lima_submit *submit)
goto err_out2;
}
- fence = lima_sched_context_queue_task(
- submit->ctx->context + submit->pipe, submit->task);
+ fence = lima_sched_context_queue_task(submit->task);
for (i = 0; i < submit->nr_bos; i++) {
if (submit->bos[i].flags & LIMA_SUBMIT_BO_WRITE)
diff --git a/drivers/gpu/drm/lima/lima_sched.c
b/drivers/gpu/drm/lima/lima_sched.c
index 38f755580507..e968b5a8f0b0 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -177,13 +177,12 @@ void lima_sched_context_fini(struct lima_sched_pipe *pipe,
drm_sched_entity_fini(&context->base);
}
-struct dma_fence *lima_sched_context_queue_task(struct lima_sched_context
*context,
- struct lima_sched_task *task)
+struct dma_fence *lima_sched_context_queue_task(struct lima_sched_task *task)
{
struct dma_fence *fence = dma_fence_get(&task->base.s_fence->finished);
trace_lima_task_submit(task);
- drm_sched_entity_push_job(&task->base, &context->base);
+ drm_sched_entity_push_job(&task->base);
return fence;
}
diff --git a/drivers/gpu/drm/lima/lima_sched.h
b/drivers/gpu/drm/lima/lima_sched.h
index 90f03c48ef4a..ac70006b0e26 100644
--- a/drivers/gpu/drm/lima/lima_sched.h
+++ b/drivers/gpu/drm/lima/lima_sched.h
@@ -98,8 +98,7 @@ int lima_sched_context_init(struct lima_sched_pipe *pipe,
atomic_t *guilty);
void lim
[Intel-gfx] [PATCH v4 06/18] drm/panfrost: use scheduler dependency tracking
Just deletes some code that's now more shared.
Note that thanks to the split into drm_sched_job_init/arm we can now
easily pull the _init() part from under the submission lock way ahead
where we're adding the sync file in-fences as dependencies.
v2: Correctly clean up the partially set up job, now that job_init()
and job_arm() are apart (Emma).
Reviewed-by: Steven Price
Signed-off-by: Daniel Vetter
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ---
drivers/gpu/drm/panfrost/panfrost_job.c | 37 +++--
drivers/gpu/drm/panfrost/panfrost_job.h | 5 +---
3 files changed, 17 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 1ffaef5ec5ff..9f53bea07d61 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -218,7 +218,7 @@ panfrost_copy_in_sync(struct drm_device *dev,
if (ret)
goto fail;
- ret = drm_gem_fence_array_add(&job->deps, fence);
+ ret = drm_sched_job_await_fence(&job->base, fence);
if (ret)
goto fail;
@@ -236,7 +236,7 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
void *data,
struct drm_panfrost_submit *args = data;
struct drm_syncobj *sync_out = NULL;
struct panfrost_job *job;
- int ret = 0;
+ int ret = 0, slot;
if (!args->jc)
return -EINVAL;
@@ -258,14 +258,20 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
void *data,
kref_init(&job->refcount);
- xa_init_flags(&job->deps, XA_FLAGS_ALLOC);
-
job->pfdev = pfdev;
job->jc = args->jc;
job->requirements = args->requirements;
job->flush_id = panfrost_gpu_get_latest_flush_id(pfdev);
job->file_priv = file->driver_priv;
+ slot = panfrost_job_get_slot(job);
+
+ ret = drm_sched_job_init(&job->base,
+&job->file_priv->sched_entity[slot],
+NULL);
+ if (ret)
+ goto fail_job_put;
+
ret = panfrost_copy_in_sync(dev, file, args, job);
if (ret)
goto fail_job;
@@ -283,6 +289,8 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
void *data,
drm_syncobj_replace_fence(sync_out, job->render_done_fence);
fail_job:
+ drm_sched_job_cleanup(&job->base);
+fail_job_put:
panfrost_job_put(job);
fail_out_sync:
if (sync_out)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 4bc962763e1f..86c843d8822e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -102,7 +102,7 @@ static struct dma_fence *panfrost_fence_create(struct
panfrost_device *pfdev, in
return &fence->base;
}
-static int panfrost_job_get_slot(struct panfrost_job *job)
+int panfrost_job_get_slot(struct panfrost_job *job)
{
/* JS0: fragment jobs.
* JS1: vertex/tiler jobs
@@ -242,13 +242,13 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
static int panfrost_acquire_object_fences(struct drm_gem_object **bos,
int bo_count,
- struct xarray *deps)
+ struct drm_sched_job *job)
{
int i, ret;
for (i = 0; i < bo_count; i++) {
/* panfrost always uses write mode in its current uapi */
- ret = drm_gem_fence_array_add_implicit(deps, bos[i], true);
+ ret = drm_sched_job_await_implicit(job, bos[i], true);
if (ret)
return ret;
}
@@ -269,31 +269,21 @@ static void panfrost_attach_object_fences(struct
drm_gem_object **bos,
int panfrost_job_push(struct panfrost_job *job)
{
struct panfrost_device *pfdev = job->pfdev;
- int slot = panfrost_job_get_slot(job);
- struct drm_sched_entity *entity = &job->file_priv->sched_entity[slot];
struct ww_acquire_ctx acquire_ctx;
int ret = 0;
-
ret = drm_gem_lock_reservations(job->bos, job->bo_count,
&acquire_ctx);
if (ret)
return ret;
mutex_lock(&pfdev->sched_lock);
-
- ret = drm_sched_job_init(&job->base, entity, NULL);
- if (ret) {
- mutex_unlock(&pfdev->sched_lock);
- goto unlock;
- }
-
drm_sched_job_arm(&job->base);
job->render_done_fence = dma_fence_get(&job->base.s_fence->finished);
ret = panfrost_acquire_object_fences(job->bos, job->bo_count,
-
[Intel-gfx] [PATCH v4 05/18] drm/sched: improve docs around drm_sched_entity
I found a few too many things that are tricky and not documented, so I
started typing.
I found a few more things that looked broken while typing, see the
varios FIXME in drm_sched_entity.
Also some of the usual logics:
- actually include sched_entity.c declarations, that was lost in the
move here: 620e762f9a98 ("drm/scheduler: move entity handling into
separate file")
- Ditch the kerneldoc for internal functions, keep the comments where
they're describing more than what the function name already implies.
- Switch drm_sched_entity to inline docs.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-mm.rst | 3 +
drivers/gpu/drm/scheduler/sched_entity.c | 85 -
include/drm/gpu_scheduler.h | 145 ++-
3 files changed, 146 insertions(+), 87 deletions(-)
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index d5a73fa2c9ef..0198fa43d254 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -504,3 +504,6 @@ Scheduler Function References
.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c
:export:
+
+.. kernel-doc:: drivers/gpu/drm/scheduler/sched_entity.c
+ :export:
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index e4d33db1eb45..27e1573af96e 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -45,8 +45,14 @@
* @guilty: atomic_t set to 1 when a job on this queue
* is found to be guilty causing a timeout
*
- * Note: the sched_list should have at least one element to schedule
- * the entity
+ * Note that the &sched_list must have at least one element to schedule the
entity.
+ *
+ * For changing @priority later on at runtime see
+ * drm_sched_entity_set_priority(). For changing the set of schedulers
+ * @sched_list at runtime see drm_sched_entity_modify_sched().
+ *
+ * An entity is cleaned up by callind drm_sched_entity_fini(). See also
+ * drm_sched_entity_destroy().
*
* Returns 0 on success or a negative error code on failure.
*/
@@ -92,6 +98,11 @@ EXPORT_SYMBOL(drm_sched_entity_init);
* @sched_list: the list of new drm scheds which will replace
* existing entity->sched_list
* @num_sched_list: number of drm sched in sched_list
+ *
+ * Note that this must be called under the same common lock for @entity as
+ * drm_sched_job_arm() and drm_sched_entity_push_job(), or the driver needs to
+ * guarantee through some other means that this is never called while new jobs
+ * can be pushed to @entity.
*/
void drm_sched_entity_modify_sched(struct drm_sched_entity *entity,
struct drm_gpu_scheduler **sched_list,
@@ -104,13 +115,6 @@ void drm_sched_entity_modify_sched(struct drm_sched_entity
*entity,
}
EXPORT_SYMBOL(drm_sched_entity_modify_sched);
-/**
- * drm_sched_entity_is_idle - Check if entity is idle
- *
- * @entity: scheduler entity
- *
- * Returns true if the entity does not have any unscheduled jobs.
- */
static bool drm_sched_entity_is_idle(struct drm_sched_entity *entity)
{
rmb(); /* for list_empty to work without lock */
@@ -123,13 +127,7 @@ static bool drm_sched_entity_is_idle(struct
drm_sched_entity *entity)
return false;
}
-/**
- * drm_sched_entity_is_ready - Check if entity is ready
- *
- * @entity: scheduler entity
- *
- * Return true if entity could provide a job.
- */
+/* Return true if entity could provide a job. */
bool drm_sched_entity_is_ready(struct drm_sched_entity *entity)
{
if (spsc_queue_peek(&entity->job_queue) == NULL)
@@ -192,14 +190,7 @@ long drm_sched_entity_flush(struct drm_sched_entity
*entity, long timeout)
}
EXPORT_SYMBOL(drm_sched_entity_flush);
-/**
- * drm_sched_entity_kill_jobs_cb - helper for drm_sched_entity_kill_jobs
- *
- * @f: signaled fence
- * @cb: our callback structure
- *
- * Signal the scheduler finished fence when the entity in question is killed.
- */
+/* Signal the scheduler finished fence when the entity in question is killed.
*/
static void drm_sched_entity_kill_jobs_cb(struct dma_fence *f,
struct dma_fence_cb *cb)
{
@@ -224,14 +215,6 @@ drm_sched_job_dependency(struct drm_sched_job *job,
return NULL;
}
-/**
- * drm_sched_entity_kill_jobs - Make sure all remaining jobs are killed
- *
- * @entity: entity which is cleaned up
- *
- * Makes sure that all remaining jobs in an entity are killed before it is
- * destroyed.
- */
static void drm_sched_entity_kill_jobs(struct drm_sched_entity *entity)
{
struct drm_sched_job *job;
@@ -273,9 +256,11 @@ static void drm_sched_entity_kill_jobs(struct
drm_sched_entity *entity)
*
* @entity: scheduler entity
*
- * This should be called after @drm_sched_entity_do_release. It goes over the
- * entity and signals all jobs with an error code if the process was killed.
+ * Cleanups up @entity which has been in
[Intel-gfx] [PATCH v4 03/18] drm/sched: Add dependency tracking
Instead of just a callback we can just glue in the gem helpers that
panfrost, v3d and lima currently use. There's really not that many
ways to skin this cat.
On the naming bikeshed: The idea for using _await_ to denote adding
dependencies to a job comes from i915, where that's used quite
extensively all over the place, in lots of datastructures.
v2/3: Rebased.
Reviewed-by: Steven Price (v1)
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: Andrey Grodzovsky
Cc: Lee Jones
Cc: Nirmoy Das
Cc: Boris Brezillon
Cc: Luben Tuikov
Cc: Alex Deucher
Cc: Jack Zhang
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/gpu/drm/scheduler/sched_entity.c | 18 +++-
drivers/gpu/drm/scheduler/sched_main.c | 103 +++
include/drm/gpu_scheduler.h | 31 ++-
3 files changed, 146 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 89e3f6eaf519..381fbf462ea7 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -211,6 +211,19 @@ static void drm_sched_entity_kill_jobs_cb(struct dma_fence
*f,
job->sched->ops->free_job(job);
}
+static struct dma_fence *
+drm_sched_job_dependency(struct drm_sched_job *job,
+struct drm_sched_entity *entity)
+{
+ if (!xa_empty(&job->dependencies))
+ return xa_erase(&job->dependencies, job->last_dependency++);
+
+ if (job->sched->ops->dependency)
+ return job->sched->ops->dependency(job, entity);
+
+ return NULL;
+}
+
/**
* drm_sched_entity_kill_jobs - Make sure all remaining jobs are killed
*
@@ -229,7 +242,7 @@ static void drm_sched_entity_kill_jobs(struct
drm_sched_entity *entity)
struct drm_sched_fence *s_fence = job->s_fence;
/* Wait for all dependencies to avoid data corruptions */
- while ((f = job->sched->ops->dependency(job, entity)))
+ while ((f = drm_sched_job_dependency(job, entity)))
dma_fence_wait(f, false);
drm_sched_fence_scheduled(s_fence);
@@ -419,7 +432,6 @@ static bool drm_sched_entity_add_dependency_cb(struct
drm_sched_entity *entity)
*/
struct drm_sched_job *drm_sched_entity_pop_job(struct drm_sched_entity *entity)
{
- struct drm_gpu_scheduler *sched = entity->rq->sched;
struct drm_sched_job *sched_job;
sched_job = to_drm_sched_job(spsc_queue_peek(&entity->job_queue));
@@ -427,7 +439,7 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct
drm_sched_entity *entity)
return NULL;
while ((entity->dependency =
- sched->ops->dependency(sched_job, entity))) {
+ drm_sched_job_dependency(sched_job, entity))) {
trace_drm_sched_job_wait_dep(sched_job, entity->dependency);
if (drm_sched_entity_add_dependency_cb(entity))
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 454cb6164bdc..84c30badb78e 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -603,6 +603,8 @@ int drm_sched_job_init(struct drm_sched_job *job,
INIT_LIST_HEAD(&job->list);
+ xa_init_flags(&job->dependencies, XA_FLAGS_ALLOC);
+
return 0;
}
EXPORT_SYMBOL(drm_sched_job_init);
@@ -637,6 +639,98 @@ void drm_sched_job_arm(struct drm_sched_job *job)
}
EXPORT_SYMBOL(drm_sched_job_arm);
+/**
+ * drm_sched_job_await_fence - adds the fence as a job dependency
+ * @job: scheduler job to add the dependencies to
+ * @fence: the dma_fence to add to the list of dependencies.
+ *
+ * Note that @fence is consumed in both the success and error cases.
+ *
+ * Returns:
+ * 0 on success, or an error on failing to expand the array.
+ */
+int drm_sched_job_await_fence(struct drm_sched_job *job,
+ struct dma_fence *fence)
+{
+ struct dma_fence *entry;
+ unsigned long index;
+ u32 id = 0;
+ int ret;
+
+ if (!fence)
+ return 0;
+
+ /* Deduplicate if we already depend on a fence from the same context.
+* This lets the size of the array of deps scale with the number of
+* engines involved, rather than the number of BOs.
+*/
+ xa_for_each(&job->dependencies, index, entry) {
+ if (entry->context != fence->context)
+ continue;
+
+ if (dma_fence_is_later(fence, entry)) {
+ dma_fence_put(entry);
+ xa_store(&job->dependencies, index, fence, GFP_KERNEL);
+ } else {
+ dma_fence_put(fence);
+ }
+ return 0;
+ }
+
+ ret = xa_alloc(&job->dependencies, &id, fence, xa_limit_32b,
[Intel-gfx] [PATCH v4 02/18] drm/sched: Barriers are needed for entity->last_scheduled
It might be good enough on x86 with just READ_ONCE, but the write side should then at least be WRITE_ONCE because x86 has total store order. It's definitely not enough on arm. Fix this proplery, which means - explain the need for the barrier in both places - point at the other side in each comment Also pull out the !sched_list case as the first check, so that the code flow is clearer. While at it sprinkle some comments around because it was very non-obvious to me what's actually going on here and why. Note that we really need full barriers here, at first I thought store-release and load-acquire on ->last_scheduled would be enough, but we actually requiring ordering between that and the queue state. v2: Put smp_rmp() in the right place and fix up comment (Andrey) Signed-off-by: Daniel Vetter Cc: "Christian König" Cc: Steven Price Cc: Daniel Vetter Cc: Andrey Grodzovsky Cc: Lee Jones Cc: Boris Brezillon --- drivers/gpu/drm/scheduler/sched_entity.c | 27 ++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index f7347c284886..89e3f6eaf519 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -439,8 +439,16 @@ struct drm_sched_job *drm_sched_entity_pop_job(struct drm_sched_entity *entity) dma_fence_set_error(&sched_job->s_fence->finished, -ECANCELED); dma_fence_put(entity->last_scheduled); + entity->last_scheduled = dma_fence_get(&sched_job->s_fence->finished); + /* +* If the queue is empty we allow drm_sched_entity_select_rq() to +* locklessly access ->last_scheduled. This only works if we set the +* pointer before we dequeue and if we a write barrier here. +*/ + smp_wmb(); + spsc_queue_pop(&entity->job_queue); return sched_job; } @@ -459,10 +467,25 @@ void drm_sched_entity_select_rq(struct drm_sched_entity *entity) struct drm_gpu_scheduler *sched; struct drm_sched_rq *rq; - if (spsc_queue_count(&entity->job_queue) || !entity->sched_list) + /* single possible engine and already selected */ + if (!entity->sched_list) + return; + + /* queue non-empty, stay on the same engine */ + if (spsc_queue_count(&entity->job_queue)) return; - fence = READ_ONCE(entity->last_scheduled); + /* +* Only when the queue is empty are we guaranteed that the scheduler +* thread cannot change ->last_scheduled. To enforce ordering we need +* a read barrier here. See drm_sched_entity_pop_job() for the other +* side. +*/ + smp_rmb(); + + fence = entity->last_scheduled; + + /* stay on the same engine if the previous job hasn't finished */ if (fence && !dma_fence_is_signaled(fence)) return; -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 01/18] drm/sched: Split drm_sched_job_init
This is a very confusingly named function, because not just does it init an object, it arms it and provides a point of no return for pushing a job into the scheduler. It would be nice if that's a bit clearer in the interface. But the real reason is that I want to push the dependency tracking helpers into the scheduler code, and that means drm_sched_job_init must be called a lot earlier, without arming the job. v2: - don't change .gitignore (Steven) - don't forget v3d (Emma) v3: Emma noticed that I leak the memory allocated in drm_sched_job_init if we bail out before the point of no return in subsequent driver patches. To be able to fix this change drm_sched_job_cleanup() so it can handle being called both before and after drm_sched_job_arm(). Also improve the kerneldoc for this. v4: - Fix the drm_sched_job_cleanup logic, I inverted the booleans, as usual (Melissa) - Christian pointed out that drm_sched_entity_select_rq() also needs to be moved into drm_sched_job_arm, which made me realize that the job->id definitely needs to be moved too. Shuffle things to fit between job_init and job_arm. v5: Reshuffle the split between init/arm once more, amdgpu abuses drm_sched.ready to signal gpu reset failures. Also document this somewhat. (Christian) Cc: Melissa Wen Acked-by: Steven Price (v2) Signed-off-by: Daniel Vetter Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: Qiang Yu Cc: Rob Herring Cc: Tomeu Vizoso Cc: Steven Price Cc: Alyssa Rosenzweig Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: Masahiro Yamada Cc: Kees Cook Cc: Adam Borowski Cc: Nick Terrell Cc: Mauro Carvalho Chehab Cc: Paul Menzel Cc: Sami Tolvanen Cc: Viresh Kumar Cc: Alex Deucher Cc: Dave Airlie Cc: Nirmoy Das Cc: Deepak R Varma Cc: Lee Jones Cc: Kevin Wang Cc: Chen Li Cc: Luben Tuikov Cc: "Marek Olšák" Cc: Dennis Li Cc: Maarten Lankhorst Cc: Andrey Grodzovsky Cc: Sonny Jiang Cc: Boris Brezillon Cc: Tian Tao Cc: etna...@lists.freedesktop.org Cc: l...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: Emma Anholt --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 + drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 + drivers/gpu/drm/lima/lima_sched.c| 2 + drivers/gpu/drm/panfrost/panfrost_job.c | 2 + drivers/gpu/drm/scheduler/sched_entity.c | 6 +-- drivers/gpu/drm/scheduler/sched_fence.c | 19 --- drivers/gpu/drm/scheduler/sched_main.c | 69 drivers/gpu/drm/v3d/v3d_gem.c| 2 + include/drm/gpu_scheduler.h | 7 ++- 10 files changed, 91 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index c5386d13eb4a..a4ec092af9a7 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1226,6 +1226,8 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p, if (r) goto error_unlock; + drm_sched_job_arm(&job->base); + /* No memory allocation is allowed while holding the notifier lock. * The lock is held until amdgpu_cs_submit is finished and fence is * added to BOs. diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c index d33e6d97cc89..5ddb955d2315 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c @@ -170,6 +170,8 @@ int amdgpu_job_submit(struct amdgpu_job *job, struct drm_sched_entity *entity, if (r) return r; + drm_sched_job_arm(&job->base); + *f = dma_fence_get(&job->base.s_fence->finished); amdgpu_job_free_resources(job); drm_sched_entity_push_job(&job->base, entity); diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c b/drivers/gpu/drm/etnaviv/etnaviv_sched.c index feb6da1b6ceb..05f412204118 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c @@ -163,6 +163,8 @@ int etnaviv_sched_push_job(struct drm_sched_entity *sched_entity, if (ret) goto out_unlock; + drm_sched_job_arm(&submit->sched_job); + submit->out_fence = dma_fence_get(&submit->sched_job.s_fence->finished); submit->out_fence_id = idr_alloc_cyclic(&submit->gpu->fence_idr, submit->out_fence, 0, diff --git a/drivers/gpu/drm/lima/lima_sched.c b/drivers/gpu/drm/lima/lima_sched.c index dba8329937a3..38f755580507 100644 --- a/drivers/gpu/drm/lima/lima_sched.c +++ b/drivers/gpu/drm/lima/lima_sched.c @@ -129,6 +129,8 @@ int lima_sched_task_init(struct lima_sched_task *task, return err; } + drm_sched_job_arm(&task->base); + task->num_bos = num_bos; task->vm = lima_vm_get(vm); diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/driver
[Intel-gfx] [PATCH v4 00/18] drm/sched dependency tracking and dma-resv fixes
Hi all, Quick new version since the previous one was a bit too broken: - dropped the bug-on patch to avoid breaking amdgpu's gpu reset failure games - another attempt at splitting job_init/arm, hopefully we're getting there. Note that Christian has brought up a bikeshed on the new functions to add dependencies to drm_sched_jobs. I'm happy to repaint, if there's some kind of consensus on what it should be. Testing and review very much welcome, as usual. Cheers, Daniel Daniel Vetter (18): drm/sched: Split drm_sched_job_init drm/sched: Barriers are needed for entity->last_scheduled drm/sched: Add dependency tracking drm/sched: drop entity parameter from drm_sched_push_job drm/sched: improve docs around drm_sched_entity drm/panfrost: use scheduler dependency tracking drm/lima: use scheduler dependency tracking drm/v3d: Move drm_sched_job_init to v3d_job_init drm/v3d: Use scheduler dependency handling drm/etnaviv: Use scheduler dependency handling drm/gem: Delete gem array fencing helpers drm/sched: Don't store self-dependencies drm/sched: Check locking in drm_sched_job_await_implicit drm/msm: Don't break exclusive fence ordering drm/etnaviv: Don't break exclusive fence ordering drm/i915: delete exclude argument from i915_sw_fence_await_reservation drm/i915: Don't break exclusive fence ordering dma-resv: Give the docs a do-over Documentation/gpu/drm-mm.rst | 3 + drivers/dma-buf/dma-resv.c| 24 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 4 +- drivers/gpu/drm/drm_gem.c | 96 - drivers/gpu/drm/etnaviv/etnaviv_gem.h | 5 +- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 64 +++--- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 65 +- drivers/gpu/drm/etnaviv/etnaviv_sched.h | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 8 +- drivers/gpu/drm/i915/i915_sw_fence.c | 6 +- drivers/gpu/drm/i915/i915_sw_fence.h | 1 - drivers/gpu/drm/lima/lima_gem.c | 7 +- drivers/gpu/drm/lima/lima_sched.c | 28 +-- drivers/gpu/drm/lima/lima_sched.h | 6 +- drivers/gpu/drm/msm/msm_gem_submit.c | 3 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 16 +- drivers/gpu/drm/panfrost/panfrost_job.c | 39 +--- drivers/gpu/drm/panfrost/panfrost_job.h | 5 +- drivers/gpu/drm/scheduler/sched_entity.c | 140 +++-- drivers/gpu/drm/scheduler/sched_fence.c | 19 +- drivers/gpu/drm/scheduler/sched_main.c| 181 +++-- drivers/gpu/drm/v3d/v3d_drv.h | 6 +- drivers/gpu/drm/v3d/v3d_gem.c | 115 +-- drivers/gpu/drm/v3d/v3d_sched.c | 44 + include/drm/drm_gem.h | 5 - include/drm/gpu_scheduler.h | 186 ++ include/linux/dma-buf.h | 7 + include/linux/dma-resv.h | 104 +- 31 files changed, 672 insertions(+), 528 deletions(-) -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 32/47] drm/i915: Reset GPU immediately if submission is disabled
On 6/24/2021 00:05, Matthew Brost wrote:
If submission is disabled by the backend for any reason, reset the GPU
immediately in the heartbeat code as the backend can't be reenabled
until the GPU is reset.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 63 +++
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 4 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 9 +++
drivers/gpu/drm/i915/i915_scheduler.c | 6 ++
drivers/gpu/drm/i915/i915_scheduler.h | 6 ++
drivers/gpu/drm/i915/i915_scheduler_types.h | 5 ++
6 files changed, 80 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index b6a305e6a974..a8495364d906 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -70,12 +70,30 @@ static void show_heartbeat(const struct i915_request *rq,
{
struct drm_printer p = drm_debug_printer("heartbeat");
- intel_engine_dump(engine, &p,
- "%s heartbeat {seqno:%llx:%lld, prio:%d} not
ticking\n",
- engine->name,
- rq->fence.context,
- rq->fence.seqno,
- rq->sched.attr.priority);
+ if (!rq) {
+ intel_engine_dump(engine, &p,
+ "%s heartbeat not ticking\n",
+ engine->name);
+ } else {
+ intel_engine_dump(engine, &p,
+ "%s heartbeat {seqno:%llx:%lld, prio:%d} not
ticking\n",
+ engine->name,
+ rq->fence.context,
+ rq->fence.seqno,
+ rq->sched.attr.priority);
+ }
+}
+
+static void
+reset_engine(struct intel_engine_cs *engine, struct i915_request *rq)
+{
+ if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
+ show_heartbeat(rq, engine);
+
+ intel_gt_handle_error(engine->gt, engine->mask,
+ I915_ERROR_CAPTURE,
+ "stopped heartbeat on %s",
+ engine->name);
}
static void heartbeat(struct work_struct *wrk)
@@ -102,6 +120,11 @@ static void heartbeat(struct work_struct *wrk)
if (intel_gt_is_wedged(engine->gt))
goto out;
+ if (i915_sched_engine_disabled(engine->sched_engine)) {
+ reset_engine(engine, engine->heartbeat.systole);
+ goto out;
+ }
+
if (engine->heartbeat.systole) {
long delay = READ_ONCE(engine->props.heartbeat_interval_ms);
@@ -139,13 +162,7 @@ static void heartbeat(struct work_struct *wrk)
engine->sched_engine->schedule(rq, &attr);
local_bh_enable();
} else {
- if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
- show_heartbeat(rq, engine);
-
- intel_gt_handle_error(engine->gt, engine->mask,
- I915_ERROR_CAPTURE,
- "stopped heartbeat on %s",
- engine->name);
+ reset_engine(engine, rq);
}
rq->emitted_jiffies = jiffies;
@@ -194,6 +211,26 @@ void intel_engine_park_heartbeat(struct intel_engine_cs
*engine)
i915_request_put(fetch_and_zero(&engine->heartbeat.systole));
}
+void intel_gt_unpark_heartbeats(struct intel_gt *gt)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, gt, id)
+ if (intel_engine_pm_is_awake(engine))
+ intel_engine_unpark_heartbeat(engine);
+
+}
+
+void intel_gt_park_heartbeats(struct intel_gt *gt)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, gt, id)
+ intel_engine_park_heartbeat(engine);
+}
+
void intel_engine_init_heartbeat(struct intel_engine_cs *engine)
{
INIT_DELAYED_WORK(&engine->heartbeat.work, heartbeat);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
index a488ea3e84a3..5da6d809a87a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.h
@@ -7,6 +7,7 @@
#define INTEL_ENGINE_HEARTBEAT_H
struct intel_engine_cs;
+struct intel_gt;
void intel_engine_init_heartbeat(struct intel_engine_cs *engine);
@@ -16,6 +17,9 @@ int intel_engine_set_heartbeat(struct intel_engine_cs *engine,
void intel_engine_park_heartbeat(struct intel_engine_cs *engine);
void intel_engine_unpark_heartbeat(struct int
Re: [Intel-gfx] [PATCH 31/47] drm/i915/guc: Reset implementation for new GuC interface
On 6/24/2021 00:05, Matthew Brost wrote:
Reset implementation for new GuC interface. This is the legacy reset
implementation which is called when the i915 owns the engine hang check.
Future patches will offload the engine hang check to GuC but we will
continue to maintain this legacy path as a fallback and this code path
is also required if the GuC dies.
With the new GuC interface it is not possible to reset individual
engines - it is only possible to reset the GPU entirely. This patch
forces an entire chip reset if any engine hangs.
There seems to be quite a lot more code being changed in the patch than
is described above. Sure, it's all in order to support resets but there
is a lot happening to request/context management, support for GuC
submission enable/disable, etc. It feels like this patch really should
be split into a couple of prep patches followed by the actual reset
support. Plus see couple of minor comments below.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 3 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 7 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 +
.../drm/i915/gt/intel_execlists_submission.c | 40 ++
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 18 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 22 +
drivers/gpu/drm/i915/gt/mock_engine.c | 31 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 13 -
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 581 ++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 39 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 3 +
drivers/gpu/drm/i915/i915_request.c | 41 +-
drivers/gpu/drm/i915/i915_request.h | 2 +
15 files changed, 649 insertions(+), 171 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index b24a1b7a3f88..2f01437056a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -392,6 +392,9 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
spin_lock_init(&ce->guc_state.lock);
INIT_LIST_HEAD(&ce->guc_state.fences);
+ spin_lock_init(&ce->guc_active.lock);
+ INIT_LIST_HEAD(&ce->guc_active.requests);
+
ce->guc_id = GUC_INVALID_LRC_ID;
INIT_LIST_HEAD(&ce->guc_id_link);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 6945963a31ba..b63c8cf7823b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -165,6 +165,13 @@ struct intel_context {
struct list_head fences;
} guc_state;
+ struct {
+ /** lock: protects everything in guc_active */
+ spinlock_t lock;
+ /** requests: active requests on this context */
+ struct list_head requests;
+ } guc_active;
+
/* GuC scheduling state that does not require a lock. */
atomic_t guc_sched_state_no_lock;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index e7cb6a06db9d..f9d264c008e8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -426,6 +426,12 @@ struct intel_engine_cs {
void (*release)(struct intel_engine_cs *engine);
+ /*
+* Add / remove request from engine active tracking
+*/
+ void(*add_active_request)(struct i915_request *rq);
+ void(*remove_active_request)(struct i915_request *rq);
+
struct intel_engine_execlists execlists;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index c10ea6080752..c301a2d088b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3118,6 +3118,42 @@ static void execlists_park(struct intel_engine_cs
*engine)
cancel_timer(&engine->execlists.preempt);
}
+static void add_to_engine(struct i915_request *rq)
+{
+ lockdep_assert_held(&rq->engine->sched_engine->lock);
+ list_move_tail(&rq->sched.link, &rq->engine->sched_engine->requests);
+}
+
+static void remove_from_engine(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine, *locked;
+
+ /*
+* Virtual engines complicate acquiring the engine timeline lock,
+* as their rq->engine pointer is not stable until under that
+* engine lock. The simple ploy we use is to take the lock then
+* check that the rq still belongs to the newly locked engine.
+*/
+ locked = READ_ONCE(rq->engine);
+ spin_lock_irq(&locked->sched_engine-
[Intel-gfx] ✗ Fi.CI.BUILD: failure for GuC submission support (rev2)
== Series Details == Series: GuC submission support (rev2) URL : https://patchwork.freedesktop.org/series/91840/ State : failure == Summary == Applying: drm/i915/guc: Relax CTB response timeout Applying: drm/i915/guc: Improve error message for unsolicited CT response Applying: drm/i915/guc: Increase size of CTB buffers Applying: drm/i915/guc: Add non blocking CTB send function Applying: drm/i915/guc: Add stall timer to non blocking CTB send function Applying: drm/i915/guc: Optimize CTB writes and reads Applying: drm/i915/guc: Module load failure test for CT buffer creation Applying: drm/i915/guc: Add new GuC interface defines and structures Applying: drm/i915/guc: Remove GuC stage descriptor, add lrc descriptor Applying: drm/i915/guc: Add lrc descriptor context lookup array Applying: drm/i915/guc: Implement GuC submission tasklet Applying: drm/i915/guc: Add bypass tasklet submission path to GuC Applying: drm/i915/guc: Implement GuC context operations for new inteface Applying: drm/i915/guc: Insert fence on context when deregistering Applying: drm/i915/guc: Defer context unpin until scheduling is disabled Applying: drm/i915/guc: Disable engine barriers with GuC during unpin Applying: drm/i915/guc: Extend deregistration fence to schedule disable Applying: drm/i915: Disable preempt busywait when using GuC scheduling Applying: drm/i915/guc: Ensure request ordering via completion fences Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_request.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_request.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_request.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0019 drm/i915/guc: Ensure request ordering via completion fences 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 30/47] drm/i915/guc: Direct all breadcrumbs for a class to single breadcrumbs
On 6/24/2021 00:04, Matthew Brost wrote:
With GuC virtual engines the physical engine which a request executes
and completes on isn't known to the i915. Therefore we can't attach a
request to a physical engines breadcrumbs. To work around this we create
a single breadcrumbs per engine class when using GuC submission and
direct all physical engine interrupts to this breadcrumbs.
Signed-off-by: Matthew Brost
CC: John Harrison
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 41 +---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.h | 14 +++-
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 7 ++
drivers/gpu/drm/i915/gt/intel_engine.h| 3 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 28 +++-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 -
.../drm/i915/gt/intel_execlists_submission.c | 2 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 4 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 67 +--
9 files changed, 131 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 38cc42783dfb..2007dc6f6b99 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -15,28 +15,14 @@
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
-static bool irq_enable(struct intel_engine_cs *engine)
+static bool irq_enable(struct intel_breadcrumbs *b)
{
- if (!engine->irq_enable)
- return false;
-
- /* Caller disables interrupts */
- spin_lock(&engine->gt->irq_lock);
- engine->irq_enable(engine);
- spin_unlock(&engine->gt->irq_lock);
-
- return true;
+ return intel_engine_irq_enable(b->irq_engine);
}
-static void irq_disable(struct intel_engine_cs *engine)
+static void irq_disable(struct intel_breadcrumbs *b)
{
- if (!engine->irq_disable)
- return;
-
- /* Caller disables interrupts */
- spin_lock(&engine->gt->irq_lock);
- engine->irq_disable(engine);
- spin_unlock(&engine->gt->irq_lock);
+ intel_engine_irq_disable(b->irq_engine);
}
static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
@@ -57,7 +43,7 @@ static void __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
WRITE_ONCE(b->irq_armed, true);
/* Requests may have completed before we could enable the interrupt. */
- if (!b->irq_enabled++ && irq_enable(b->irq_engine))
+ if (!b->irq_enabled++ && b->irq_enable(b))
irq_work_queue(&b->irq_work);
}
@@ -76,7 +62,7 @@ static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
{
GEM_BUG_ON(!b->irq_enabled);
if (!--b->irq_enabled)
- irq_disable(b->irq_engine);
+ b->irq_disable(b);
WRITE_ONCE(b->irq_armed, false);
intel_gt_pm_put_async(b->irq_engine->gt);
@@ -281,7 +267,7 @@ intel_breadcrumbs_create(struct intel_engine_cs *irq_engine)
if (!b)
return NULL;
- b->irq_engine = irq_engine;
+ kref_init(&b->ref);
spin_lock_init(&b->signalers_lock);
INIT_LIST_HEAD(&b->signalers);
@@ -290,6 +276,10 @@ intel_breadcrumbs_create(struct intel_engine_cs
*irq_engine)
spin_lock_init(&b->irq_lock);
init_irq_work(&b->irq_work, signal_irq_work);
+ b->irq_engine = irq_engine;
+ b->irq_enable = irq_enable;
+ b->irq_disable = irq_disable;
+
return b;
}
@@ -303,9 +293,9 @@ void intel_breadcrumbs_reset(struct intel_breadcrumbs *b)
spin_lock_irqsave(&b->irq_lock, flags);
if (b->irq_enabled)
- irq_enable(b->irq_engine);
+ b->irq_enable(b);
else
- irq_disable(b->irq_engine);
+ b->irq_disable(b);
spin_unlock_irqrestore(&b->irq_lock, flags);
}
@@ -325,11 +315,14 @@ void __intel_breadcrumbs_park(struct intel_breadcrumbs *b)
}
}
-void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
+void intel_breadcrumbs_free(struct kref *kref)
{
+ struct intel_breadcrumbs *b = container_of(kref, typeof(*b), ref);
+
irq_work_sync(&b->irq_work);
GEM_BUG_ON(!list_empty(&b->signalers));
GEM_BUG_ON(b->irq_armed);
+
kfree(b);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
index 3ce5ce270b04..72105b74663d 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
@@ -17,7 +17,7 @@ struct intel_breadcrumbs;
struct intel_breadcrumbs *
intel_breadcrumbs_create(struct intel_engine_cs *irq_engine);
-void intel_breadcrumbs_free(struct intel_breadcrumbs *b);
+void intel_breadcrumbs_free(struct kref *kref);
void intel_breadcrumbs_reset(struct intel_breadcrumbs *b);
void __intel_breadcrumbs_park(struct intel_breadcrumbs *b);
@@ -48,4 +48,16 @@ void i915_reque
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: address potential UAF bugs with drm_master ptrs
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs
URL : https://patchwork.freedesktop.org/series/92439/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10334_full -> Patchwork_20576_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20576_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20576_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_20576_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_dc@dc5-dpms:
- shard-iclb: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-iclb6/igt@i915_pm...@dc5-dpms.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-iclb3/igt@i915_pm...@dc5-dpms.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_ccs@pipe-a-bad-aux-stride-yf_tiled_ccs:
- {shard-rkl}:[FAIL][3] ([i915#3678]) -> [SKIP][4] +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-rkl-5/igt@kms_ccs@pipe-a-bad-aux-stride-yf_tiled_ccs.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-rkl-6/igt@kms_ccs@pipe-a-bad-aux-stride-yf_tiled_ccs.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc:
- {shard-rkl}:NOTRUN -> [SKIP][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-rkl-1/igt@kms_dit...@fb-8bpc-vs-panel-6bpc.html
Known issues
Here are the changes found in Patchwork_20576_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@drm_import_export@flink:
- shard-glk: [PASS][6] -> [INCOMPLETE][7] ([i915#2369])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-glk4/igt@drm_import_exp...@flink.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-glk8/igt@drm_import_exp...@flink.html
* igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +4
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) +2 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-tglb3/igt@gem_exec_fair@basic-p...@bcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-tglb6/igt@gem_exec_fair@basic-p...@bcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2849])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-iclb2/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_exec_whisper@basic-forked:
- shard-glk: [PASS][16] -> [DMESG-WARN][17] ([i915#118] /
[i915#95]) +1 similar issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-glk1/igt@gem_exec_whis...@basic-forked.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-glk5/igt@gem_exec_whis...@basic-forked.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][18] -> [SKIP][19] ([i915#2190])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/shard-tglb3/igt@gem_huc_c...@huc-copy.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-tglb6/igt@gem_huc_c...@huc-copy.html
* igt@gem_pwrite@basic-exhaustion:
- shard-snb: NOTRUN -> [WARN][20] ([i915#2658])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-snb2/igt@gem_pwr...@basic-exhaustion.html
* igt@gem_userptr_blits@vma-merge:
- shard-snb: NOTRUN -> [FAIL][21] ([i915#2724])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/shard-snb2/igt@gem_userptr_bl.
Re: [Intel-gfx] [PATCH 02/16] drm/i915/guc/slpc: Initial definitions for slpc
On 7/10/2021 7:27 AM, Michal Wajdeczko wrote:
Hi Vinay,
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Add macros to check for slpc support. This feature is currently supported
for gen12+ and enabled whenever guc submission is enabled/selected.
please try to use consistent names across all patches:
s/slpc/SLPC
s/gen12/Gen12
s/guc/GuC
Signed-off-by: Vinay Belgaumkar
Signed-off-by: Sundaresan Sujaritha
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 21 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 16 ++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 --
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 1 +
6 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 979128e28372..b9a809f2d221 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -157,6 +157,7 @@ void intel_guc_init_early(struct intel_guc *guc)
intel_guc_ct_init_early(&guc->ct);
intel_guc_log_init_early(&guc->log);
intel_guc_submission_init_early(guc);
+ intel_guc_slpc_init_early(guc);
mutex_init(&guc->send_mutex);
spin_lock_init(&guc->irq_lock);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 5d94cf482516..e5a456918b88 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -57,6 +57,8 @@ struct intel_guc {
bool submission_supported;
bool submission_selected;
+ bool slpc_supported;
+ bool slpc_selected;
struct i915_vma *ads_vma;
struct __guc_ads_blob *ads_blob;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9c102bf0c8e3..e2644a05f298 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2351,6 +2351,27 @@ void intel_guc_submission_init_early(struct intel_guc
*guc)
guc->submission_selected = __guc_submission_selected(guc);
}
+static bool __guc_slpc_supported(struct intel_guc *guc)
hmm, easy to confuse with intel_guc_slpc_is_supported, so maybe:
__detect_slpc_supported()
ok.
(yes, I know you were following code above)
+{
+ /* GuC slpc is unavailable for pre-Gen12 */
s/slpc/SLPC
+ return guc->submission_supported &&
+ GRAPHICS_VER(guc_to_gt(guc)->i915) >= 12;
+}
+
+static bool __guc_slpc_selected(struct intel_guc *guc)
+{
+ if (!intel_guc_slpc_is_supported(guc))
+ return false;
+
+ return guc->submission_selected;
+}
+
+void intel_guc_slpc_init_early(struct intel_guc *guc)
+{
+ guc->slpc_supported = __guc_slpc_supported(guc);
+ guc->slpc_selected = __guc_slpc_selected(guc);
+}
in patch 4/16 you are introducing intel_guc_slpc.c|h so to have proper
encapsulation better to define this function as
void intel_guc_slpc_init_early(struct intel_guc_slpc *slpc) { }
the uc_state_checkers force the use of struct intel_guc *guc as the
param. don't think I can change that to refer to slpc instead.
static inline bool intel_guc_slpc_is_supported(struct intel_guc *guc)
{
return guc->slpc_supported;
}
slpc_supported needs to be inside the guc struct.
and move it to intel_guc_slpc.c
+
static inline struct intel_context *
g2h_context_lookup(struct intel_guc *guc, u32 desc_idx)
{
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
index be767eb6ff71..7ae5fd052faf 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
@@ -13,6 +13,7 @@
struct drm_printer;
struct intel_engine_cs;
+void intel_guc_slpc_init_early(struct intel_guc *guc);
it really does not belong to this .h
void intel_guc_submission_init_early(struct intel_guc *guc);
int intel_guc_submission_init(struct intel_guc *guc);
void intel_guc_submission_enable(struct intel_guc *guc);
@@ -50,4 +51,19 @@ static inline bool intel_guc_submission_is_used(struct
intel_guc *guc)
return intel_guc_is_used(guc) && intel_guc_submission_is_wanted(guc);
}
+static inline bool intel_guc_slpc_is_supported(struct intel_guc *guc)
+{
+ return guc->slpc_supported;
+}
+
+static inline bool intel_guc_slpc_is_wanted(struct intel_guc *guc)
+{
+ return guc->slpc_selected;
+}
+
+static inline bool intel_guc_slpc_is_used(struct intel_guc *guc)
+{
+ return intel_guc_submission_is_used(guc) &&
intel_guc_slpc_is_wanted(guc);
+}
did you try to define them in intel_guc_slpc.h ?
note that to avoid circular dependencies you can define slpc struct in
intel_guc_slpc_types.h and then
Re: [Intel-gfx] [PATCH 29/47] drm/i915/guc: Disable bonding extension with GuC submission
On 6/24/2021 00:04, Matthew Brost wrote:
Update the bonding extension to return -ENODEV when using GuC submission
as this extension fundamentally will not work with the GuC submission
interface.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8a9293e0ca92..0429aa4172bf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1674,6 +1674,11 @@ set_engines__bond(struct i915_user_extension __user
*base, void *data)
}
virtual = set->engines->engines[idx]->engine;
+ if (intel_engine_uses_guc(virtual)) {
+ DRM_DEBUG("bonding extension not supported with GuC
submission");
+ return -ENODEV;
+ }
+
err = check_user_mbz(&ext->flags);
if (err)
return err;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 28/47] drm/i915: Hold reference to intel_context over life of i915_request
On 6/24/2021 00:04, Matthew Brost wrote:
Hold a reference to the intel_context over life of an i915_request.
Without this an i915_request can exist after the context has been
destroyed (e.g. request retired, context closed, but user space holds a
reference to the request from an out fence). In the case of GuC
submission + virtual engine, the engine that the request references is
also destroyed which can trigger bad pointer dref in fence ops (e.g.
Maybe quickly explain a why this is different for GuC submission vs
execlist? Presumably it is about only decomposing virtual engines to
physical ones in execlist mode?
i915_fence_get_driver_name). We could likely change
i915_fence_get_driver_name to avoid touching the engine but let's just
be safe and hold the intel_context reference.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_request.c | 54 -
1 file changed, 22 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index de9deb95b8b1..dec5a35c9aa2 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -126,39 +126,17 @@ static void i915_fence_release(struct dma_fence *fence)
i915_sw_fence_fini(&rq->semaphore);
/*
-* Keep one request on each engine for reserved use under mempressure
-*
-* We do not hold a reference to the engine here and so have to be
-* very careful in what rq->engine we poke. The virtual engine is
-* referenced via the rq->context and we released that ref during
-* i915_request_retire(), ergo we must not dereference a virtual
-* engine here. Not that we would want to, as the only consumer of
-* the reserved engine->request_pool is the power management parking,
-* which must-not-fail, and that is only run on the physical engines.
-*
-* Since the request must have been executed to be have completed,
-* we know that it will have been processed by the HW and will
-* not be unsubmitted again, so rq->engine and rq->execution_mask
-* at this point is stable. rq->execution_mask will be a single
-* bit if the last and _only_ engine it could execution on was a
-* physical engine, if it's multiple bits then it started on and
-* could still be on a virtual engine. Thus if the mask is not a
-* power-of-two we assume that rq->engine may still be a virtual
-* engine and so a dangling invalid pointer that we cannot dereference
-*
-* For example, consider the flow of a bonded request through a virtual
-* engine. The request is created with a wide engine mask (all engines
-* that we might execute on). On processing the bond, the request mask
-* is reduced to one or more engines. If the request is subsequently
-* bound to a single engine, it will then be constrained to only
-* execute on that engine and never returned to the virtual engine
-* after timeslicing away, see __unwind_incomplete_requests(). Thus we
-* know that if the rq->execution_mask is a single bit, rq->engine
-* can be a physical engine with the exact corresponding mask.
+* Keep one request on each engine for reserved use under mempressure,
+* do not use with virtual engines as this really is only needed for
+* kernel contexts.
*/
- if (is_power_of_2(rq->execution_mask) &&
- !cmpxchg(&rq->engine->request_pool, NULL, rq))
+ if (!intel_engine_is_virtual(rq->engine) &&
+ !cmpxchg(&rq->engine->request_pool, NULL, rq)) {
+ intel_context_put(rq->context);
return;
+ }
+
+ intel_context_put(rq->context);
The put is actually unconditional? So it could be moved before the if?
John.
kmem_cache_free(global.slab_requests, rq);
}
@@ -977,7 +955,18 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
}
}
- rq->context = ce;
+ /*
+* Hold a reference to the intel_context over life of an i915_request.
+* Without this an i915_request can exist after the context has been
+* destroyed (e.g. request retired, context closed, but user space holds
+* a reference to the request from an out fence). In the case of GuC
+* submission + virtual engine, the engine that the request references
+* is also destroyed which can trigger bad pointer dref in fence ops
+* (e.g. i915_fence_get_driver_name). We could likely change these
+* functions to avoid touching the engine but let's just be safe and
+* hold the intel_context reference.
+*/
+ rq->context = intel_context_get(ce);
rq->engine = ce->engine;
rq->ring = ce->ring;
rq->execution_mask = ce->engine->mask;
@@ -1054,6 +1043,7 @@ __i915_request_create(struct intel_
Re: [Intel-gfx] [PATCH 27/47] drm/i915: Track 'serial' counts for virtual engines
On 6/24/2021 00:04, Matthew Brost wrote:
From: John Harrison
The serial number tracking of engines happens at the backend of
request submission and was expecting to only be given physical
engines. However, in GuC submission mode, the decomposition of virtual
to physical engines does not happen in i915. Instead, requests are
submitted to their virtual engine mask all the way through to the
hardware (i.e. to GuC). This would mean that the heart beat code
thinks the physical engines are idle due to the serial number not
incrementing.
This patch updates the tracking to decompose virtual engines into
their physical constituents and tracks the request against each. This
is not entirely accurate as the GuC will only be issuing the request
to one physical engine. However, it is the best that i915 can do given
that it has no knowledge of the GuC's scheduling decisions.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Need to pull in the updated subject line and commit description from
Tvrtko in the RFC patch set review.
John.
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 ++
.../gpu/drm/i915/gt/intel_execlists_submission.c | 6 ++
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 6 ++
drivers/gpu/drm/i915/gt/mock_engine.c| 6 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c| 16
drivers/gpu/drm/i915/i915_request.c | 4 +++-
6 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 5b91068ab277..1dc59e6c9a92 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -388,6 +388,8 @@ struct intel_engine_cs {
void(*park)(struct intel_engine_cs *engine);
void(*unpark)(struct intel_engine_cs *engine);
+ void (*bump_serial)(struct intel_engine_cs *engine);
+
void(*set_default_submission)(struct intel_engine_cs
*engine);
const struct intel_context_ops *cops;
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index bd4ced794ff9..9cfb8800a0e6 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3203,6 +3203,11 @@ static void execlists_release(struct intel_engine_cs
*engine)
lrc_fini_wa_ctx(engine);
}
+static void execlist_bump_serial(struct intel_engine_cs *engine)
+{
+ engine->serial++;
+}
+
static void
logical_ring_default_vfuncs(struct intel_engine_cs *engine)
{
@@ -3212,6 +3217,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->cops = &execlists_context_ops;
engine->request_alloc = execlists_request_alloc;
+ engine->bump_serial = execlist_bump_serial;
engine->reset.prepare = execlists_reset_prepare;
engine->reset.rewind = execlists_reset_rewind;
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 5d42a12ef3d6..e1506b280df1 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1044,6 +1044,11 @@ static void setup_irq(struct intel_engine_cs *engine)
}
}
+static void ring_bump_serial(struct intel_engine_cs *engine)
+{
+ engine->serial++;
+}
+
static void setup_common(struct intel_engine_cs *engine)
{
struct drm_i915_private *i915 = engine->i915;
@@ -1063,6 +1068,7 @@ static void setup_common(struct intel_engine_cs *engine)
engine->cops = &ring_context_ops;
engine->request_alloc = ring_request_alloc;
+ engine->bump_serial = ring_bump_serial;
/*
* Using a global execution timeline; the previous final breadcrumb is
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
b/drivers/gpu/drm/i915/gt/mock_engine.c
index 68970398e4ef..9203c766db80 100644
--- a/drivers/gpu/drm/i915/gt/mock_engine.c
+++ b/drivers/gpu/drm/i915/gt/mock_engine.c
@@ -292,6 +292,11 @@ static void mock_engine_release(struct intel_engine_cs
*engine)
intel_engine_fini_retire(engine);
}
+static void mock_bump_serial(struct intel_engine_cs *engine)
+{
+ engine->serial++;
+}
+
struct intel_engine_cs *mock_engine(struct drm_i915_private *i915,
const char *name,
int id)
@@ -318,6 +323,7 @@ struct intel_engine_cs *mock_engine(struct drm_i915_private
*i915,
engine->base.cops = &mock_context_ops;
engine->base.request_alloc = mock_request_alloc;
+ engine->base.bump_serial = mock_bump_serial;
engine->base.emit_flush = mock_emit_flush;
engine->base.emit_fini_breadcrumb = mock_emit_breadcrumb;
engine->base.submit_request = mock_submit_request;
diff --git a/drivers/gpu/drm/i915/gt/u
Re: [Intel-gfx] [PATCH 16/47] drm/i915/guc: Disable engine barriers with GuC during unpin
On Mon, Jul 12, 2021 at 7:57 PM John Harrison wrote:
>
> On 7/9/2021 20:00, Matthew Brost wrote:
> > On Fri, Jul 09, 2021 at 03:53:29PM -0700, John Harrison wrote:
> >> On 6/24/2021 00:04, Matthew Brost wrote:
> >>> Disable engine barriers for unpinning with GuC. This feature isn't
> >>> needed with the GuC as it disables context scheduling before unpinning
> >>> which guarantees the HW will not reference the context. Hence it is
> >>> not necessary to defer unpinning until a kernel context request
> >>> completes on each engine in the context engine mask.
> >>>
> >>> Cc: John Harrison
> >>> Signed-off-by: Matthew Brost
> >>> Signed-off-by: Daniele Ceraolo Spurio
> >>> ---
> >>>drivers/gpu/drm/i915/gt/intel_context.c| 2 +-
> >>>drivers/gpu/drm/i915/gt/intel_context.h| 1 +
> >>>drivers/gpu/drm/i915/gt/selftest_context.c | 10 ++
> >>>3 files changed, 12 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> >>> b/drivers/gpu/drm/i915/gt/intel_context.c
> >>> index 1499b8aace2a..7f97753ab164 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> >>> @@ -80,7 +80,7 @@ static int intel_context_active_acquire(struct
> >>> intel_context *ce)
> >>> __i915_active_acquire(&ce->active);
> >>> - if (intel_context_is_barrier(ce))
> >>> + if (intel_context_is_barrier(ce) || intel_engine_uses_guc(ce->engine))
> >>> return 0;
> >> Would be better to have a scheduler flag to say whether barriers are
> >> required or not. That would prevent polluting front end code with back end
> >> details.
> >>
> > I guess an engine flag is slightly better but I still don't love that
> > as we have to test if the context is a barrier (kernel context) and then
> > call a function that is basically backend specific after. IMO we really
> > need to push all of this to a vfunc. If you really want me to make this
> > an engine flag I can, but in the end it just seems like that will
> > trash the code (adding an engine flag just to remove it). I think this
> > is just a clean up we write down, and figure out a bit later as nothing
> > is functionally wrong + quite clear that it is something that should be
> > cleaned up.
> >
> > Matt
> Flag, vfunc, whatever. I just mean that it would be better to abstract
> it out in some manner. Maybe a flag/vfunc on the ce object? That way it
> would swallow the 'ignore kernel contexts' test as well. But yes,
> probably best to add it to the todo list and move on as it is not going
> to be a two minute quick fix. I've added a comment to the Jira, so...
The plan is:
- merge guc backend
- convert over to drm/scheduler as a proper interface between higher
levels and the scheduler backend
- shovel as much as reasonable of the execlist specifics into the
execlist backend
Right now our frontend code is essentially designed to assume the
execlist backend is the true way to build a scheduler, and everything
else is a special case. We can't reasonable fix this by sprinkling
lots of vfuns all over the place, and hence we imo shouldn't try, at
least not until the big picture is in much better shape.
-Daniel
> Reviewed-by: John Harrison
>
>
> >
> >> John.
> >>
> >>
> >>> /* Preallocate tracking nodes */
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> >>> b/drivers/gpu/drm/i915/gt/intel_context.h
> >>> index 8a7199afbe61..a592a9605dc8 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> >>> @@ -16,6 +16,7 @@
> >>>#include "intel_engine_types.h"
> >>>#include "intel_ring_types.h"
> >>>#include "intel_timeline_types.h"
> >>> +#include "uc/intel_guc_submission.h"
> >>>#define CE_TRACE(ce, fmt, ...) do {
> >>> \
> >>> const struct intel_context *ce__ = (ce);\
> >>> diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
> >>> b/drivers/gpu/drm/i915/gt/selftest_context.c
> >>> index 26685b927169..fa7b99a671dd 100644
> >>> --- a/drivers/gpu/drm/i915/gt/selftest_context.c
> >>> +++ b/drivers/gpu/drm/i915/gt/selftest_context.c
> >>> @@ -209,7 +209,13 @@ static int __live_active_context(struct
> >>> intel_engine_cs *engine)
> >>> * This test makes sure that the context is kept alive until a
> >>> * subsequent idle-barrier (emitted when the engine wakeref hits 0
> >>> * with no more outstanding requests).
> >>> +*
> >>> +* In GuC submission mode we don't use idle barriers and we instead
> >>> +* get a message from the GuC to signal that it is safe to unpin the
> >>> +* context from memory.
> >>> */
> >>> + if (intel_engine_uses_guc(engine))
> >>> + return 0;
> >>> if (intel_engine_pm_is_awake(engine)) {
> >>> pr_err("%s is awake before starting %s!\n",
> >>> @@ -357,7 +363,11 @@ static int __live_remote_context(struct
> >>> intel_engine_cs *engine)
Re: [Intel-gfx] [PATCH 25/47] drm/i915: Add intel_context tracing
On 6/24/2021 00:04, Matthew Brost wrote:
Add intel_context tracing. These trace points are particular helpful
when debugging the GuC firmware and can be enabled via
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS kernel config option.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 6 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 14 ++
drivers/gpu/drm/i915/i915_trace.h | 148 +-
3 files changed, 166 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 7f97753ab164..b24a1b7a3f88 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -8,6 +8,7 @@
#include "i915_drv.h"
#include "i915_globals.h"
+#include "i915_trace.h"
#include "intel_context.h"
#include "intel_engine.h"
@@ -28,6 +29,7 @@ static void rcu_context_free(struct rcu_head *rcu)
{
struct intel_context *ce = container_of(rcu, typeof(*ce), rcu);
+ trace_intel_context_free(ce);
kmem_cache_free(global.slab_ce, ce);
}
@@ -46,6 +48,7 @@ intel_context_create(struct intel_engine_cs *engine)
return ERR_PTR(-ENOMEM);
intel_context_init(ce, engine);
+ trace_intel_context_create(ce);
return ce;
}
@@ -268,6 +271,8 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
+ trace_intel_context_do_pin(ce);
+
err_unlock:
mutex_unlock(&ce->pin_mutex);
err_post_unpin:
@@ -323,6 +328,7 @@ void __intel_context_do_unpin(struct intel_context *ce, int
sub)
*/
intel_context_get(ce);
intel_context_active_release(ce);
+ trace_intel_context_do_unpin(ce);
intel_context_put(ce);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index c2327eebc09c..d605af0d66e6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -348,6 +348,7 @@ static int guc_add_request(struct intel_guc *guc, struct
i915_request *rq)
err = intel_guc_send_nb(guc, action, len, g2h_len_dw);
if (!enabled && !err) {
+ trace_intel_context_sched_enable(ce);
atomic_inc(&guc->outstanding_submission_g2h);
set_context_enabled(ce);
} else if (!enabled) {
@@ -812,6 +813,8 @@ static int register_context(struct intel_context *ce)
u32 offset = intel_guc_ggtt_offset(guc, guc->lrc_desc_pool) +
ce->guc_id * sizeof(struct guc_lrc_desc);
+ trace_intel_context_register(ce);
+
return __guc_action_register_context(guc, ce->guc_id, offset);
}
@@ -831,6 +834,8 @@ static int deregister_context(struct intel_context *ce, u32 guc_id)
{
struct intel_guc *guc = ce_to_guc(ce);
+ trace_intel_context_deregister(ce);
+
return __guc_action_deregister_context(guc, guc_id);
}
@@ -905,6 +910,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce)
* GuC before registering this context.
*/
if (context_registered) {
+ trace_intel_context_steal_guc_id(ce);
set_context_wait_for_deregister_to_register(ce);
intel_context_get(ce);
@@ -963,6 +969,7 @@ static void __guc_context_sched_disable(struct intel_guc *guc,
GEM_BUG_ON(guc_id == GUC_INVALID_LRC_ID);
+ trace_intel_context_sched_disable(ce);
intel_context_get(ce);
guc_submission_busy_loop(guc, action, ARRAY_SIZE(action),
@@ -1119,6 +1126,9 @@ static void __guc_signal_context_fence(struct
intel_context *ce)
lockdep_assert_held(&ce->guc_state.lock);
+ if (!list_empty(&ce->guc_state.fences))
+ trace_intel_context_fence_release(ce);
+
list_for_each_entry(rq, &ce->guc_state.fences, guc_fence_link)
i915_sw_fence_complete(&rq->submit);
@@ -1529,6 +1539,8 @@ int intel_guc_deregister_done_process_msg(struct intel_guc *guc,
if (unlikely(!ce))
return -EPROTO;
+ trace_intel_context_deregister_done(ce);
+
if (context_wait_for_deregister_to_register(ce)) {
struct intel_runtime_pm *runtime_pm =
&ce->engine->gt->i915->runtime_pm;
@@ -1580,6 +1592,8 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
return -EPROTO;
}
+ trace_intel_context_sched_done(ce);
+
if (context_pending_enable(ce)) {
clr_context_pending_enable(ce);
} else if (context_pending_disable(ce)) {
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index b02d04b6c8f6..97c2e83984ed 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -818,8 +818,8 @@ DECLARE_EVENT_CLASS(i915_request,
);
DEFI
Re: [Intel-gfx] [PATCH 24/47] drm/i915/guc: Add several request trace points
On 6/24/2021 00:04, Matthew Brost wrote:
Add trace points for request dependencies and GuC submit. Extended
existing request trace points to include submit fence value,, guc_id,
Excessive punctuation. Or maybe should say 'fence value, tail, guc_id'?
With that fixed:
Reviewed-by: John Harrison
and ring tail value.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++
drivers/gpu/drm/i915/i915_request.c | 3 ++
drivers/gpu/drm/i915/i915_trace.h | 39 ++-
3 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 89b3c7e5d15b..c2327eebc09c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -422,6 +422,7 @@ static int guc_dequeue_one_context(struct intel_guc *guc)
guc->stalled_request = last;
return false;
}
+ trace_i915_request_guc_submit(last);
}
guc->stalled_request = NULL;
@@ -642,6 +643,8 @@ static int guc_bypass_tasklet_submit(struct intel_guc *guc,
ret = guc_add_request(guc, rq);
if (ret == -EBUSY)
guc->stalled_request = rq;
+ else
+ trace_i915_request_guc_submit(rq);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d92c9f25c9f4..7f7aa096e873 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1344,6 +1344,9 @@ __i915_request_await_execution(struct i915_request *to,
return err;
}
+ trace_i915_request_dep_to(to);
+ trace_i915_request_dep_from(from);
+
/* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->sched_engine->schedule) {
err = i915_sched_node_add_dependency(&to->sched,
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 6778ad2a14a4..b02d04b6c8f6 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -794,22 +794,27 @@ DECLARE_EVENT_CLASS(i915_request,
TP_STRUCT__entry(
__field(u32, dev)
__field(u64, ctx)
+__field(u32, guc_id)
__field(u16, class)
__field(u16, instance)
__field(u32, seqno)
+__field(u32, tail)
),
TP_fast_assign(
__entry->dev = rq->engine->i915->drm.primary->index;
__entry->class = rq->engine->uabi_class;
__entry->instance = rq->engine->uabi_instance;
+ __entry->guc_id = rq->context->guc_id;
__entry->ctx = rq->fence.context;
__entry->seqno = rq->fence.seqno;
+ __entry->tail = rq->tail;
),
- TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u",
+ TP_printk("dev=%u, engine=%u:%u, guc_id=%u, ctx=%llu, seqno=%u,
tail=%u",
__entry->dev, __entry->class, __entry->instance,
- __entry->ctx, __entry->seqno)
+ __entry->guc_id, __entry->ctx, __entry->seqno,
+ __entry->tail)
);
DEFINE_EVENT(i915_request, i915_request_add,
@@ -818,6 +823,21 @@ DEFINE_EVENT(i915_request, i915_request_add,
);
#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
+DEFINE_EVENT(i915_request, i915_request_dep_to,
+TP_PROTO(struct i915_request *rq),
+TP_ARGS(rq)
+);
+
+DEFINE_EVENT(i915_request, i915_request_dep_from,
+TP_PROTO(struct i915_request *rq),
+TP_ARGS(rq)
+);
+
+DEFINE_EVENT(i915_request, i915_request_guc_submit,
+TP_PROTO(struct i915_request *rq),
+TP_ARGS(rq)
+);
+
DEFINE_EVENT(i915_request, i915_request_submit,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq)
@@ -887,6 +907,21 @@ TRACE_EVENT(i915_request_out,
#else
#if !defined(TRACE_HEADER_MULTI_READ)
+static inline void
+trace_i915_request_dep_to(struct i915_request *rq)
+{
+}
+
+static inline void
+trace_i915_request_dep_from(struct i915_request *rq)
+{
+}
+
+static inline void
+trace_i915_request_guc_submit(struct i915_request *rq)
+{
+}
+
static inline void
trace_i915_request_submit(struct i915_request *rq)
{
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 23/47] drm/i915/guc: Update GuC debugfs to support new GuC
On 6/24/2021 00:04, Matthew Brost wrote:
Update GuC debugfs to support the new GuC structures.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 22
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 ++
.../gpu/drm/i915/gt/uc/intel_guc_debugfs.c| 23 +++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 52 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 4 ++
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
6 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index e0f92e28350c..4ed074df88e5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -1135,3 +1135,25 @@ void intel_guc_ct_event_handler(struct intel_guc_ct *ct)
ct_try_receive_message(ct);
}
+
+void intel_guc_log_ct_info(struct intel_guc_ct *ct,
+ struct drm_printer *p)
+{
+ if (!ct->enabled) {
+ drm_puts(p, "CT disabled\n");
+ return;
+ }
+
+ drm_printf(p, "H2G Space: %u\n",
+ atomic_read(&ct->ctbs.send.space) * 4);
+ drm_printf(p, "Head: %u\n",
+ ct->ctbs.send.desc->head);
+ drm_printf(p, "Tail: %u\n",
+ ct->ctbs.send.desc->tail);
+ drm_printf(p, "G2H Space: %u\n",
+ atomic_read(&ct->ctbs.recv.space) * 4);
+ drm_printf(p, "Head: %u\n",
+ ct->ctbs.recv.desc->head);
+ drm_printf(p, "Tail: %u\n",
+ ct->ctbs.recv.desc->tail);
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index ab1b79ab960b..f62eb06b32fc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -16,6 +16,7 @@
struct i915_vma;
struct intel_guc;
+struct drm_printer;
/**
* DOC: Command Transport (CT).
@@ -106,4 +107,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32
*action, u32 len,
u32 *response_buf, u32 response_buf_size, u32 flags);
void intel_guc_ct_event_handler(struct intel_guc_ct *ct);
+void intel_guc_log_ct_info(struct intel_guc_ct *ct, struct drm_printer *p);
+
#endif /* _INTEL_GUC_CT_H_ */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
index fe7cb7b29a1e..62b9ce0fafaa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
@@ -9,6 +9,8 @@
#include "intel_guc.h"
#include "intel_guc_debugfs.h"
#include "intel_guc_log_debugfs.h"
+#include "gt/uc/intel_guc_ct.h"
+#include "gt/uc/intel_guc_submission.h"
static int guc_info_show(struct seq_file *m, void *data)
{
@@ -22,16 +24,35 @@ static int guc_info_show(struct seq_file *m, void *data)
drm_puts(&p, "\n");
intel_guc_log_info(&guc->log, &p);
- /* Add more as required ... */
+ if (!intel_guc_submission_is_used(guc))
+ return 0;
+
+ intel_guc_log_ct_info(&guc->ct, &p);
+ intel_guc_log_submission_info(guc, &p);
return 0;
}
DEFINE_GT_DEBUGFS_ATTRIBUTE(guc_info);
+static int guc_registered_contexts_show(struct seq_file *m, void *data)
+{
+ struct intel_guc *guc = m->private;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ if (!intel_guc_submission_is_used(guc))
+ return -ENODEV;
+
+ intel_guc_log_context_info(guc, &p);
+
+ return 0;
+}
+DEFINE_GT_DEBUGFS_ATTRIBUTE(guc_registered_contexts);
+
void intel_guc_debugfs_register(struct intel_guc *guc, struct dentry *root)
{
static const struct debugfs_gt_file files[] = {
{ "guc_info", &guc_info_fops, NULL },
+ { "guc_registered_contexts", &guc_registered_contexts_fops,
NULL },
};
if (!intel_guc_is_supported(guc))
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index d1a28283a9ae..89b3c7e5d15b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1600,3 +1600,55 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
return 0;
}
+
+void intel_guc_log_submission_info(struct intel_guc *guc,
+ struct drm_printer *p)
+{
+ struct i915_sched_engine *sched_engine = guc->sched_engine;
+ struct rb_node *rb;
+ unsigned long flags;
+
+ drm_printf(p, "GuC Number Outstanding Submission G2H: %u\n",
+ atomic_read(&guc->outstanding_submission_g2h));
+ drm_printf(p, "GuC tasklet count: %u\n\n",
+ atomic_read(&sched_engine->tasklet.count));
Does sched_engine need a null check?
+
+ spin_lock_irqsave(&sched_engine->lock, flag
Re: [Intel-gfx] [PATCH 16/47] drm/i915/guc: Disable engine barriers with GuC during unpin
On 7/9/2021 20:00, Matthew Brost wrote:
On Fri, Jul 09, 2021 at 03:53:29PM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Disable engine barriers for unpinning with GuC. This feature isn't
needed with the GuC as it disables context scheduling before unpinning
which guarantees the HW will not reference the context. Hence it is
not necessary to defer unpinning until a kernel context request
completes on each engine in the context engine mask.
Cc: John Harrison
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_context.c| 2 +-
drivers/gpu/drm/i915/gt/intel_context.h| 1 +
drivers/gpu/drm/i915/gt/selftest_context.c | 10 ++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 1499b8aace2a..7f97753ab164 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -80,7 +80,7 @@ static int intel_context_active_acquire(struct intel_context
*ce)
__i915_active_acquire(&ce->active);
- if (intel_context_is_barrier(ce))
+ if (intel_context_is_barrier(ce) || intel_engine_uses_guc(ce->engine))
return 0;
Would be better to have a scheduler flag to say whether barriers are
required or not. That would prevent polluting front end code with back end
details.
I guess an engine flag is slightly better but I still don't love that
as we have to test if the context is a barrier (kernel context) and then
call a function that is basically backend specific after. IMO we really
need to push all of this to a vfunc. If you really want me to make this
an engine flag I can, but in the end it just seems like that will
trash the code (adding an engine flag just to remove it). I think this
is just a clean up we write down, and figure out a bit later as nothing
is functionally wrong + quite clear that it is something that should be
cleaned up.
Matt
Flag, vfunc, whatever. I just mean that it would be better to abstract
it out in some manner. Maybe a flag/vfunc on the ce object? That way it
would swallow the 'ignore kernel contexts' test as well. But yes,
probably best to add it to the todo list and move on as it is not going
to be a two minute quick fix. I've added a comment to the Jira, so...
Reviewed-by: John Harrison
John.
/* Preallocate tracking nodes */
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 8a7199afbe61..a592a9605dc8 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -16,6 +16,7 @@
#include "intel_engine_types.h"
#include "intel_ring_types.h"
#include "intel_timeline_types.h"
+#include "uc/intel_guc_submission.h"
#define CE_TRACE(ce, fmt, ...) do { \
const struct intel_context *ce__ = (ce);\
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index 26685b927169..fa7b99a671dd 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -209,7 +209,13 @@ static int __live_active_context(struct intel_engine_cs
*engine)
* This test makes sure that the context is kept alive until a
* subsequent idle-barrier (emitted when the engine wakeref hits 0
* with no more outstanding requests).
+*
+* In GuC submission mode we don't use idle barriers and we instead
+* get a message from the GuC to signal that it is safe to unpin the
+* context from memory.
*/
+ if (intel_engine_uses_guc(engine))
+ return 0;
if (intel_engine_pm_is_awake(engine)) {
pr_err("%s is awake before starting %s!\n",
@@ -357,7 +363,11 @@ static int __live_remote_context(struct intel_engine_cs
*engine)
* on the context image remotely (intel_context_prepare_remote_request),
* which inserts foreign fences into intel_context.active, does not
* clobber the idle-barrier.
+*
+* In GuC submission mode we don't use idle barriers.
*/
+ if (intel_engine_uses_guc(engine))
+ return 0;
if (intel_engine_pm_is_awake(engine)) {
pr_err("%s is awake before starting %s!\n",
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/47] drm/i915/guc: Extend deregistration fence to schedule disable
On 7/9/2021 20:36, Matthew Brost wrote:
On Fri, Jul 09, 2021 at 03:59:11PM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Extend the deregistration context fence to fence whne a GuC context has
scheduling disable pending.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +++
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0386ccd5a481..0a6ccdf32316 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -918,7 +918,19 @@ static void guc_context_sched_disable(struct intel_context
*ce)
goto unpin;
spin_lock_irqsave(&ce->guc_state.lock, flags);
+
+ /*
+* We have to check if the context has been pinned again as another pin
+* operation is allowed to pass this function. Checking the pin count
+* here synchronizes this function with guc_request_alloc ensuring a
+* request doesn't slip through the 'context_pending_disable' fence.
+*/
The pin count is an atomic so doesn't need the spinlock. Also the above
How about?
/*
* We have to check if the context has been pinned again as another pin
* operation is allowed to pass this function. Checking the pin count,
* within ce->guc_state.lock, synchronizes this function with
* guc_request_alloc ensuring a request doesn't slip through the
* 'context_pending_disable' fence. Checking within the spin lock (can't
* sleep) ensures another process doesn't pin this context and generate
* a request before we set the 'context_pending_disable' flag here.
*/
Matt
Sounds good. With that added in:
Reviewed-by: John Harrison
comment 'checking the pin count here synchronizes ...' seems wrong. Isn't
the point that acquiring the spinlock is what synchronises with
guc_request_alloc? So the comment should be before the spinlock acquire and
should mention using the spinlock for this purpose?
John.
+ if (unlikely(atomic_add_unless(&ce->pin_count, -2, 2))) {
+ spin_unlock_irqrestore(&ce->guc_state.lock, flags);
+ return;
+ }
guc_id = prep_context_pending_disable(ce);
+
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
with_intel_runtime_pm(runtime_pm, wakeref)
@@ -1123,19 +1135,22 @@ static int guc_request_alloc(struct i915_request *rq)
out:
/*
* We block all requests on this context if a G2H is pending for a
-* context deregistration as the GuC will fail a context registration
-* while this G2H is pending. Once a G2H returns, the fence is released
-* that is blocking these requests (see guc_signal_context_fence).
+* schedule disable or context deregistration as the GuC will fail a
+* schedule enable or context registration if either G2H is pending
+* respectfully. Once a G2H returns, the fence is released that is
+* blocking these requests (see guc_signal_context_fence).
*
-* We can safely check the below field outside of the lock as it isn't
-* possible for this field to transition from being clear to set but
+* We can safely check the below fields outside of the lock as it isn't
+* possible for these fields to transition from being clear to set but
* converse is possible, hence the need for the check within the lock.
*/
- if (likely(!context_wait_for_deregister_to_register(ce)))
+ if (likely(!context_wait_for_deregister_to_register(ce) &&
+ !context_pending_disable(ce)))
return 0;
spin_lock_irqsave(&ce->guc_state.lock, flags);
- if (context_wait_for_deregister_to_register(ce)) {
+ if (context_wait_for_deregister_to_register(ce) ||
+ context_pending_disable(ce)) {
i915_sw_fence_await(&rq->submit);
list_add_tail(&rq->guc_fence_link, &ce->guc_state.fences);
@@ -1484,10 +1499,18 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
if (context_pending_enable(ce)) {
clr_context_pending_enable(ce);
} else if (context_pending_disable(ce)) {
+ /*
+* Unpin must be done before __guc_signal_context_fence,
+* otherwise a race exists between the requests getting
+* submitted + retired before this unpin completes resulting in
+* the pin_count going to zero and the context still being
+* enabled.
+*/
intel_context_sched_disable_unpin(ce);
spin_lock_irqsave(&ce->guc_state.lock, flags);
clr_context_pending_disable(ce);
+ __guc_signal_context_fence(ce);
spin_unlock_irqrestore(&ce->guc_state.lock
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Silence __iomem sparse warn
== Series Details ==
Series: series starting with [1/2] drm/i915: Silence __iomem sparse warn
URL : https://patchwork.freedesktop.org/series/92443/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10334 -> Patchwork_20577
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/index.html
Known issues
Here are the changes found in Patchwork_20577 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-cfl-8109u: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html
* igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-bdw-5557u: NOTRUN -> [SKIP][2] ([fdo#109271]) +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/fi-bdw-5557u/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-cfl-8109u: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/fi-cfl-8109u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cfl-8109u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#533])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_mmap_gtt:
- fi-cfl-8109u: NOTRUN -> [SKIP][6] ([fdo#109271]) +6 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/fi-cfl-8109u/igt@kms_psr@primary_mmap_gtt.html
* igt@runner@aborted:
- fi-cfl-8109u: NOTRUN -> [FAIL][7] ([i915#2722] / [i915#3363] /
[i915#3744])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/fi-cfl-8109u/igt@run...@aborted.html
* igt@vgem_basic@unload:
- fi-cfl-8109u: NOTRUN -> [INCOMPLETE][8] ([i915#3744])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/fi-cfl-8109u/igt@vgem_ba...@unload.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u: [INCOMPLETE][9] ([i915#155]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
* igt@gem_exec_suspend@basic-s3:
- {fi-tgl-1115g4}:[FAIL][11] ([i915#1888]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
Warnings
* igt@runner@aborted:
- fi-kbl-soraka: [FAIL][13] ([i915#2722] / [i915#3363] / [i915#3744])
-> [FAIL][14] ([i915#1569] / [i915#192] / [i915#193] / [i915#194] / [i915#2426]
/ [i915#3363])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/fi-kbl-soraka/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20577/fi-kbl-soraka/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
[i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
[i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
[i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[i915#3744]: https://gitlab.freedesktop.org/drm/intel/issues/3744
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Participating hosts (40 -> 38)
--
Missing(2): fi-bdw-samus fi-ilk-650
Build changes
-
* Linux: CI_DRM_10334 -> Patchwork_20577
CI-20190529: 20190529
CI_DRM_10334: 22eab2dac772b5eea4613e351d2f323c23912c53 @
git://anongit.freedesktop.org/gfx-ci
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Silence __iomem sparse warn
== Series Details == Series: series starting with [1/2] drm/i915: Silence __iomem sparse warn URL : https://patchwork.freedesktop.org/series/92443/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. -O:drivers/gpu/drm/i915/gt/intel_ring_submission.c:1210:24: warning: Using plain integer as NULL pointer + ___ 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 [1/2] drm/i915: Silence __iomem sparse warn
== Series Details == Series: series starting with [1/2] drm/i915: Silence __iomem sparse warn URL : https://patchwork.freedesktop.org/series/92443/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1211da9bc69c drm/i915: Silence __iomem sparse warn -:4: WARNING:EMAIL_SUBJECT: A patch subject line should describe the change not the tool that found it #4: Subject: [PATCH] drm/i915: Silence __iomem sparse warn total: 0 errors, 1 warnings, 0 checks, 8 lines checked 23873e58de17 drm/i915: s/0/NULL/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Allow using dyndbg to replace drm_debug_enabled
== Series Details == Series: Allow using dyndbg to replace drm_debug_enabled URL : https://patchwork.freedesktop.org/series/92438/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10333_full -> Patchwork_20575_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20575_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20575_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_20575_full: ### IGT changes ### Possible regressions * igt@gem_eio@hibernate: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-iclb4/igt@gem_...@hibernate.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-iclb8/igt@gem_...@hibernate.html Known issues Here are the changes found in Patchwork_20575_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-apl1/igt@gem_ctx_isolation@preservation...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-apl6/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_persistence@hostile: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-snb2/igt@gem_ctx_persiste...@hostile.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#2481] / [i915#3070]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-iclb8/igt@gem_...@unwedge-stress.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-iclb2/igt@gem_...@unwedge-stress.html - shard-snb: NOTRUN -> [FAIL][8] ([i915#3354]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-snb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2846]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-glk1/igt@gem_exec_f...@basic-deadline.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-glk7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-kbl4/igt@gem_exec_fair@basic-none-r...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-kbl6/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html - shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-tglb: NOTRUN -> [FAIL][16] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-tglb1/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_mmap_gtt@big-copy: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#307]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-skl3/igt@gem_mmap_...@big-copy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-skl6/igt@gem_mmap_...@big-copy.html * igt@gem_mmap_gtt@big-copy-odd: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#307]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-glk7/igt@gem_mmap_...@big-copy-odd.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20575/shard-glk1/igt@gem_mmap_...@big-copy-odd.html * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled: - shard-kbl: NOTRUN -> [SKIP][23] ([fdo#109271]) +92 similar issues [23
Re: [Intel-gfx] [PATCH 2/2] drm/i915: s/0/NULL/
On Mon, 12 Jul 2021 at 17:18, Ville Syrjala wrote: > > From: Ville Syrjälä > > Use NULL where appropriate. > > drivers/gpu/drm/i915/gt/intel_ring_submission.c:1210:24: warning: Using plain > integer as NULL pointer > > Signed-off-by: Ville Syrjälä Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Silence __iomem sparse warn
On Mon, 12 Jul 2021 at 17:18, Ville Syrjala wrote: > > From: Ville Syrjälä > > We don't care about __iomem mismatch when dealing with error > pointers. Silence it with ERR_CAST(). > > drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct > i915_vma *[assigned] vma > drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] > __iomem *[assigned] iomem > drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type > in assignment (different address spaces) > > Signed-off-by: Ville Syrjälä Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/ttm Initialize the ttm device and memory managers
On Mon, 12 Jul 2021 at 16:17, Colin Ian King wrote:
>
> Hi,
>
> Static analysis with Coverity on linux-next has found a potential issue
> in drivers/gpu/drm/i915/selftests/intel_memory_region.c in function
> igt_mock_fill - the problematic commit is as follows:
>
> commit d148738923fdb5077089e48ec1e6008100d0
> Author: Thomas Hellström
> Date: Wed Jun 2 10:38:08 2021 +0200
>
> drm/i915/ttm Initialize the ttm device and memory managers
>
> The analysis is as follows:
>
>
> 49 static int igt_mock_fill(void *arg)
> 50 {
> 51struct intel_memory_region *mem = arg;
> 52resource_size_t total = resource_size(&mem->region);
> 53resource_size_t page_size;
> 54resource_size_t rem;
> 55unsigned long max_pages;
> 56unsigned long page_num;
> 57LIST_HEAD(objects);
> 58int err = 0;
> 59
> 60page_size = mem->chunk_size;
> 61rem = total;
> 62 retry:
>
> value_overwrite: Overwriting previous write to max_pages with value from
> div64_u64(rem, page_size).
>
> 63max_pages = div64_u64(rem, page_size);
> 64
> 65for_each_prime_number_from(page_num, 1, max_pages) {
> 66resource_size_t size = page_num * page_size;
> 67struct drm_i915_gem_object *obj;
> 68
> 69obj = i915_gem_object_create_region(mem, size, 0);
> 70if (IS_ERR(obj)) {
> 71err = PTR_ERR(obj);
> 72break;
> 73}
> 74
> 75err = i915_gem_object_pin_pages_unlocked(obj);
> 76if (err) {
> 77i915_gem_object_put(obj);
> 78break;
> 79}
> 80
> 81list_add(&obj->st_link, &objects);
> 82rem -= size;
> 83}
> 84
> 85if (err == -ENOMEM)
> 86err = 0;
> 87if (err == -ENXIO) {
> 88if (page_num * page_size <= rem) {
> 89if (mem->is_range_manager && max_pages > 1) {
>
> Unused value (UNUSED_VALUE)
> assigned_value: Assigning value from max_pages >> 1 to max_pages here,
> but that stored value is overwritten before it can be used.
Yeah, that doesn't look good.
AFAIK this should be fixed with d53ec322dc7d ("drm/i915/ttm: switch
over to ttm_buddy_man"), which is in drm-tip, but I guess has not made
its way over to linux-next yet.
Thanks for the report.
>
> 90max_pages >>= 1;
> 91goto retry;
> 92}
> 93
>
> The right shift to max_pages on line 90 is being overwritten on line 64
> on the retry.
>
> Colin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Silence __iomem sparse warn
From: Ville Syrjälä
We don't care about __iomem mismatch when dealing with error
pointers. Silence it with ERR_CAST().
drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct
i915_vma *[assigned] vma
drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef]
__iomem *[assigned] iomem
drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type
in assignment (different address spaces)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 026c28c612f0..496b72f10b4e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1893,7 +1893,7 @@ static struct i915_vma *intel_dpt_pin(struct
i915_address_space *vm)
iomem = i915_vma_pin_iomap(vma);
i915_vma_unpin(vma);
if (IS_ERR(iomem)) {
- vma = iomem;
+ vma = ERR_CAST(iomem);
goto err;
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: s/0/NULL/
From: Ville Syrjälä Use NULL where appropriate. drivers/gpu/drm/i915/gt/intel_ring_submission.c:1210:24: warning: Using plain integer as NULL pointer Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c b/drivers/gpu/drm/i915/gt/intel_ring_submission.c index 5c4d204d07cc..696a0ff4367c 100644 --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c @@ -1207,7 +1207,7 @@ static struct i915_vma *gen7_ctx_vma(struct intel_engine_cs *engine) int size, err; if (GRAPHICS_VER(engine->i915) != 7 || engine->class != RENDER_CLASS) - return 0; + return NULL; err = gen7_ctx_switch_bb_setup(engine, NULL /* probe size */); if (err < 0) -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Explicitly track DRM clients
On Mon, Jul 12, 2021 at 04:51:42PM +0100, Tvrtko Ursulin wrote: > > On 12/07/2021 15:42, Daniel Vetter wrote: > > On Mon, Jul 12, 2021 at 01:17:12PM +0100, Tvrtko Ursulin wrote: > > > From: Tvrtko Ursulin > > > > > > Tracking DRM clients more explicitly will allow later patches to > > > accumulate past and current GPU usage in a centralised place and also > > > consolidate access to owning task pid/name. > > > > > > Unique client id is also assigned for the purpose of distinguishing/ > > > consolidating between multiple file descriptors owned by the same process. > > > > > > v2: > > > Chris Wilson: > > > * Enclose new members into dedicated structs. > > > * Protect against failed sysfs registration. > > > > > > v3: > > > * sysfs_attr_init. > > > > > > v4: > > > * Fix for internal clients. > > > > > > v5: > > > * Use cyclic ida for client id. (Chris) > > > * Do not leak pid reference. (Chris) > > > * Tidy code with some locals. > > > > > > v6: > > > * Use xa_alloc_cyclic to simplify locking. (Chris) > > > * No need to unregister individial sysfs files. (Chris) > > > * Rebase on top of fpriv kref. > > > * Track client closed status and reflect in sysfs. > > > > > > v7: > > > * Make drm_client more standalone concept. > > > > > > v8: > > > * Simplify sysfs show. (Chris) > > > * Always track name and pid. > > > > > > v9: > > > * Fix cyclic id assignment. > > > > > > v10: > > > * No need for a mutex around xa_alloc_cyclic. > > > * Refactor sysfs into own function. > > > * Unregister sysfs before freeing pid and name. > > > * Move clients setup into own function. > > > > > > v11: > > > * Call clients init directly from driver init. (Chris) > > > > > > v12: > > > * Do not fail client add on id wrap. (Maciej) > > > > > > v13 (Lucas): Rebase. > > > > > > v14: > > > * Dropped sysfs bits. > > > > > > Signed-off-by: Tvrtko Ursulin > > > Reviewed-by: Chris Wilson # v11 > > > Reviewed-by: Aravind Iddamsetty # v11 > > > Signed-off-by: Chris Wilson > > > > On the implementation: I'm not clear why this is a separate object. All > > that seems to achieve is make the lifetim fun we have in here even more > > annoying, for not real gain? > > > > What's the reasons for this separate i915_drm_client struct? The commit > > message talks about de-duping these within the same process, but with > > fdinfo I'm not seeing the relevance of this anymore. > > AFAIR I started with the new fields directly in file_priv (note file_priv > then needed to be freed via RCU due sysfs access to it!), but then the idea > there was to consolidate new members into a separate struct. Yeah separate struct makes sense for this stuff, just to encapsulate/document things a bit. It's the entire scaffolding around it that I don't think makes sense anymore with the design switch to fdinfo. > Plan was (and still is in internal) that the concept for DRM client will > gain more users/usefulness and would benefit from encapsulation from the > start. > > For instance at patch 3 in the series it does consolidate i915 users of > ctx->pid to go via ctx->client (process name as well). Those are async entry > points (compared to file_priv lifetime) from error capture and debugfs. Hm > no, debugfs is there no more, only error capture remains. > > As you say since the change of direction to use fdinfo, the asynchronous > entry path into those members from sysfs is gone. Hence if they were moved > back to file_priv, and assuming ctx->pid/name changes to be undone, then > file_priv could remain being immediately freed on file close. Or perhaps we > lose easy pid/name update for files passed over sockets. I'd have to think > about that a bit deeper. > > But essentially I think ctx->client is a cleaner design that ctx->pid and > given error capture and debugfs can be async to file_priv lifetime that's a > benefit for me. >From a quick check it's just for debug printing when a ctx hung/got banned, and for that we do want the pid - users won't have an understanding of a drm_client. I think pid is actually what we want there. > With regards to de-duping multiple fdinfo entries via client->id - that is > actually the opposite from what you suggest. Whereas with the sysfs approach > we had one entry per client, with fdinfo we have duplicates. So client->id > is essential for userspace to correctly account per client statistics. Uh why? Like if you use fdinfo and have a bunch of duplicate drm_file, then your parsing tool can aggregate them all together under the same pid. No need we do that in the kernel. If the problem is that we can't tell apart a dup'ed fd from multiple open() calls, then I think that should be solved by dropping the hash of the drm_file pointer into the fdinfo. > > Also, with the fdinfo approach, why do we still need to even track the > > pid? That can be all figured out from proc now, with much cleaner > > semantics. > > Not sure what you mean here. As explained above pid is t
[Intel-gfx] ✗ Fi.CI.IGT: failure for Per client engine busyness
== Series Details ==
Series: Per client engine busyness
URL : https://patchwork.freedesktop.org/series/92435/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10333_full -> Patchwork_20573_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20573_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20573_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_20573_full:
### IGT changes ###
Possible regressions
* igt@kms_big_fb@y-tiled-64bpp-rotate-0:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-glk9/igt@kms_big...@y-tiled-64bpp-rotate-0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/shard-glk3/igt@kms_big...@y-tiled-64bpp-rotate-0.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs:
- {shard-rkl}:[FAIL][3] ([i915#3678]) -> [SKIP][4] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-rkl-2/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/shard-rkl-6/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc:
- {shard-rkl}:NOTRUN -> [SKIP][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/shard-rkl-1/igt@kms_dit...@fb-8bpc-vs-panel-6bpc.html
### Piglit changes ###
Possible regressions
*
spec@arb_texture_cube_map_array@arb_texture_cube_map_array-fbo-cubemap-array
(NEW):
- pig-glk-j5005: NOTRUN -> [INCOMPLETE][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/pig-glk-j5005/spec@arb_texture_cube_map_array@arb_texture_cube_map_array-fbo-cubemap-array.html
New tests
-
New tests have been introduced between CI_DRM_10333_full and
Patchwork_20573_full:
### New Piglit tests (1) ###
*
spec@arb_texture_cube_map_array@arb_texture_cube_map_array-fbo-cubemap-array:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_20573_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@idempotent:
- shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +5
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/shard-snb7/igt@gem_ctx_persiste...@idempotent.html
* igt@gem_eio@unwedge-stress:
- shard-snb: NOTRUN -> [FAIL][8] ([i915#3354])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/shard-snb7/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2846])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-glk1/igt@gem_exec_f...@basic-deadline.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/shard-glk2/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar
issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-tglb: NOTRUN -> [FAIL][14] ([i915#2842])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/shard-tglb2/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl: [PASS][17] -> [FAIL][18] ([i915#2842])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10333/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20573/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Explicitly track DRM clients
On 12/07/2021 15:42, Daniel Vetter wrote: On Mon, Jul 12, 2021 at 01:17:12PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Tracking DRM clients more explicitly will allow later patches to accumulate past and current GPU usage in a centralised place and also consolidate access to owning task pid/name. Unique client id is also assigned for the purpose of distinguishing/ consolidating between multiple file descriptors owned by the same process. v2: Chris Wilson: * Enclose new members into dedicated structs. * Protect against failed sysfs registration. v3: * sysfs_attr_init. v4: * Fix for internal clients. v5: * Use cyclic ida for client id. (Chris) * Do not leak pid reference. (Chris) * Tidy code with some locals. v6: * Use xa_alloc_cyclic to simplify locking. (Chris) * No need to unregister individial sysfs files. (Chris) * Rebase on top of fpriv kref. * Track client closed status and reflect in sysfs. v7: * Make drm_client more standalone concept. v8: * Simplify sysfs show. (Chris) * Always track name and pid. v9: * Fix cyclic id assignment. v10: * No need for a mutex around xa_alloc_cyclic. * Refactor sysfs into own function. * Unregister sysfs before freeing pid and name. * Move clients setup into own function. v11: * Call clients init directly from driver init. (Chris) v12: * Do not fail client add on id wrap. (Maciej) v13 (Lucas): Rebase. v14: * Dropped sysfs bits. Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson # v11 Reviewed-by: Aravind Iddamsetty # v11 Signed-off-by: Chris Wilson On the implementation: I'm not clear why this is a separate object. All that seems to achieve is make the lifetim fun we have in here even more annoying, for not real gain? What's the reasons for this separate i915_drm_client struct? The commit message talks about de-duping these within the same process, but with fdinfo I'm not seeing the relevance of this anymore. AFAIR I started with the new fields directly in file_priv (note file_priv then needed to be freed via RCU due sysfs access to it!), but then the idea there was to consolidate new members into a separate struct. Plan was (and still is in internal) that the concept for DRM client will gain more users/usefulness and would benefit from encapsulation from the start. For instance at patch 3 in the series it does consolidate i915 users of ctx->pid to go via ctx->client (process name as well). Those are async entry points (compared to file_priv lifetime) from error capture and debugfs. Hm no, debugfs is there no more, only error capture remains. As you say since the change of direction to use fdinfo, the asynchronous entry path into those members from sysfs is gone. Hence if they were moved back to file_priv, and assuming ctx->pid/name changes to be undone, then file_priv could remain being immediately freed on file close. Or perhaps we lose easy pid/name update for files passed over sockets. I'd have to think about that a bit deeper. But essentially I think ctx->client is a cleaner design that ctx->pid and given error capture and debugfs can be async to file_priv lifetime that's a benefit for me. With regards to de-duping multiple fdinfo entries via client->id - that is actually the opposite from what you suggest. Whereas with the sysfs approach we had one entry per client, with fdinfo we have duplicates. So client->id is essential for userspace to correctly account per client statistics. Also, with the fdinfo approach, why do we still need to even track the pid? That can be all figured out from proc now, with much cleaner semantics. Not sure what you mean here. As explained above pid is tracked as replacement for current ctx->pid tracking. So for uses inside i915. Also note that even from userspace semantics of getting the pid from procfs is not necessarily clean, since actually three different file descriptors need to be open to get the whole set of data. /proc//fdinfo/ - obviously /proc//fd/ - to filter out non drm fds avoiding text parsing above file /proc//stat - to get the pid Since in the intel_gpu_top conversion I do keep the /proc/ open and do the rest via openat, I am hoping at least that's safe againt pid swaps. For the file descriptor cross check it is more questionable but worst case the drm fd check via stat could be dropped and replaced with more fdinfo text parsing. Having the pid and process name in fdinfo hence makes this easier and potentially safer. Given how we already store ctx->pid I think that should be fine. FWIW I still think the whole approach is bad since number of operations required scales with number of non drm processes (even threads) on the system. Regards, Tvrtko --- drivers/gpu/drm/i915/Makefile | 5 +- drivers/gpu/drm/i915/i915_drm_client.c | 113 + drivers/gpu/drm/i915/i915_drm_client.h | 61 + drivers/gpu/drm/i915/i915_drv.c|
Re: [Intel-gfx] [PATCH 1/4] iommu/vt-d: Disable superpage for Geminilake igfx
On Mon, Jul 12, 2021 at 07:23:07AM +0800, Lu Baolu wrote:
> On 7/10/21 12:47 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > While running "gem_exec_big --r single" from igt-gpu-tools on
> > Geminilake as soon as a 2M mapping is made I tend to get a DMAR
> > write fault. Strangely the faulting address is always a 4K page
> > and usually very far away from the 2M page that got mapped.
> > But if no 2M mappings get used I can't reproduce the fault.
> >
> > I also tried to dump the PTE for the faulting address but it actually
> > looks correct to me (ie. definitely seems to have the write bit set):
> > DMAR: DRHD: handling fault status reg 2
> > DMAR: [DMA Write] Request device [00:02.0] PASID fault addr
> > 7fa8a78000 [fault reason 05] PTE Write access is not set
> > DMAR: fault 7fa8a78000 (level=1) PTE = 149efc003
> >
> > So not really sure what's going on and this might just be full on duct
> > tape, but it seems to work here. The machine has now survived a whole day
> > running that test whereas with superpage enabled it fails in less than
> > a minute usually.
> >
> > TODO: might be nice to disable superpage only for the igfx iommu
> >instead of both iommus
>
> If all these quirks are about igfx dedicated iommu's, I would suggest to
> disable superpage only for the igfx ones.
Sure. Unfortunately there's no convenient mechanism to do that in
the iommu driver that I can immediately see. So not something I
can just whip up easily. Since you're actually familiar with the
driver maybe you can come up with a decent solution for that?
>
> Best regards,
> baolu
>
> > TODO: would be nice to use the macros from include/drm/i915_pciids.h,
> >but can't do that with DECLARE_PCI_FIXUP_HEADER()
> >
> > Cc: David Woodhouse
> > Cc: Lu Baolu
> > Cc: io...@lists.linux-foundation.org
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/iommu/intel/iommu.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> > index 19c7888cbb86..4fff2c9c86af 100644
> > --- a/drivers/iommu/intel/iommu.c
> > +++ b/drivers/iommu/intel/iommu.c
> > @@ -5617,6 +5617,16 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
> > 0x1632, quirk_iommu_igfx);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163A, quirk_iommu_igfx);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx);
> >
> > +static void quirk_iommu_nosp(struct pci_dev *dev)
> > +{
> > + pci_info(dev, "Disabling IOMMU superpage for graphics on this
> > chipset\n");
> > + intel_iommu_superpage = 0;
> > +}
> > +
> > +/* Geminilake igfx appears to have issues with superpage */
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x3184, quirk_iommu_nosp);
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x3185, quirk_iommu_nosp);
> > +
> > static void quirk_iommu_rwbf(struct pci_dev *dev)
> > {
> > if (risky_device(dev))
> >
--
Ville Syrjälä
Intel
___
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: address potential UAF bugs with drm_master ptrs
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs
URL : https://patchwork.freedesktop.org/series/92439/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10334 -> Patchwork_20576
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/index.html
Known issues
Here are the changes found in Patchwork_20576 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u: NOTRUN -> [WARN][1] ([i915#3718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html
* igt@gem_huc_copy@huc-copy:
- fi-cfl-8109u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html
* igt@kms_chamelium@dp-crc-fast:
- fi-bdw-5557u: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-cfl-8109u: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-cfl-8109u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cfl-8109u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#533])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u: NOTRUN -> [SKIP][6] ([fdo#109271]) +9 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html
* igt@kms_psr@primary_mmap_gtt:
- fi-cfl-8109u: NOTRUN -> [SKIP][7] ([fdo#109271]) +6 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-cfl-8109u/igt@kms_psr@primary_mmap_gtt.html
* igt@runner@aborted:
- fi-cfl-8109u: NOTRUN -> [FAIL][8] ([i915#2722] / [i915#3363] /
[i915#3744])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-cfl-8109u/igt@run...@aborted.html
* igt@vgem_basic@unload:
- fi-cfl-8109u: NOTRUN -> [INCOMPLETE][9] ([i915#3744])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-cfl-8109u/igt@vgem_ba...@unload.html
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][10] ([i915#3744])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-bdw-5557u/igt@vgem_ba...@unload.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-cfl-8109u: [INCOMPLETE][11] ([i915#155]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html
* igt@gem_exec_suspend@basic-s3:
- {fi-tgl-1115g4}:[FAIL][13] ([i915#1888]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
Warnings
* igt@runner@aborted:
- fi-bdw-5557u: [FAIL][15] ([i915#1602] / [i915#2029]) -> [FAIL][16]
([i915#2722] / [i915#3744])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10334/fi-bdw-5557u/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20576/fi-bdw-5557u/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[i915#3718]: https://gitlab.freedesktop.org/drm/intel/issues/3718
[i915#3744]: https://gitlab.freedesktop.org/drm/intel/issues/3744
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Participating hosts (40 -> 39)
--
Missing(1): fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10334 -> Patchw
Re: [Intel-gfx] [PATCH] dma-buf/sync_file: Don't leak fences on merge failure
Sorry for the vacation and sick leave induced delay.
I've just pushed this to drm-misc-fixes.
Thanks,
Christian.
Am 24.06.21 um 21:43 schrieb Jason Ekstrand:
I don't have drm-misc access. Mind pushing?
On Thu, Jun 24, 2021 at 12:59 PM Christian König
wrote:
Am 24.06.21 um 19:47 schrieb Jason Ekstrand:
Each add_fence() call does a dma_fence_get() on the relevant fence. In
the error path, we weren't calling dma_fence_put() so all those fences
got leaked. Also, in the krealloc_array failure case, we weren't
freeing the fences array. Instead, ensure that i and fences are always
zero-initialized and dma_fence_put() all the fences and kfree(fences) on
every error path.
Signed-off-by: Jason Ekstrand
Fixes: a02b9dc90d84 ("dma-buf/sync_file: refactor fence storage in struct
sync_file")
Cc: Gustavo Padovan
Cc: Christian König
Reviewed-by: Christian König
---
drivers/dma-buf/sync_file.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 20d9bddbb985b..394e6e1e96860 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -211,8 +211,8 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
struct sync_file *b)
{
struct sync_file *sync_file;
- struct dma_fence **fences, **nfences, **a_fences, **b_fences;
- int i, i_a, i_b, num_fences, a_num_fences, b_num_fences;
+ struct dma_fence **fences = NULL, **nfences, **a_fences, **b_fences;
+ int i = 0, i_a, i_b, num_fences, a_num_fences, b_num_fences;
sync_file = sync_file_alloc();
if (!sync_file)
@@ -236,7 +236,7 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
* If a sync_file can only be created with sync_file_merge
* and sync_file_create, this is a reasonable assumption.
*/
- for (i = i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
+ for (i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
struct dma_fence *pt_a = a_fences[i_a];
struct dma_fence *pt_b = b_fences[i_b];
@@ -277,15 +277,16 @@ static struct sync_file *sync_file_merge(const char
*name, struct sync_file *a,
fences = nfences;
}
- if (sync_file_set_fence(sync_file, fences, i) < 0) {
- kfree(fences);
+ if (sync_file_set_fence(sync_file, fences, i) < 0)
goto err;
- }
strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
return sync_file;
err:
+ while (i)
+ dma_fence_put(fences[--i]);
+ kfree(fences);
fput(sync_file->file);
return NULL;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/ttm, drm/i915: Update ttm_move_memcpy for async use
Am 28.06.21 um 13:21 schrieb Thomas Hellström:
On 6/24/21 9:30 PM, Thomas Hellström wrote:
The buffer object argument to ttm_move_memcpy was only used to
determine whether the destination memory should be cleared only
or whether we should copy data. Replace it with a "clear" bool, and
update the callers.
The intention here is to be able to use ttm_move_memcpy() async under
a dma-fence as a fallback if an accelerated blit fails in a security-
critical path where data might leak if the blit is not properly
performed. For that purpose the bo is an unsuitable argument since
its relevant members might already have changed at call time.
Finally, update the ttm_move_memcpy kerneldoc that seems to have
ended up with a stale version.
Hmm,
Not sure where the Cc: Christian König ended up, but in any case
Christian if you find this patch ok, Ack to merge through
drm_intel_gt_next?
Please send out the patch once more.
Only nit picks, but I would re-order the parameters for example.
Regards,
Christian.
/Thomas
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 20 ++--
include/drm/ttm/ttm_bo_driver.h | 2 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4e529adcdfc7..f19847abe856 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -517,7 +517,7 @@ static void __i915_ttm_move(struct
ttm_buffer_object *bo, bool clear,
obj->ttm.cached_io_st,
src_reg->region.start);
- ttm_move_memcpy(bo, dst_mem->num_pages, dst_iter, src_iter);
+ ttm_move_memcpy(clear, dst_mem->num_pages, dst_iter, src_iter);
}
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 2f57f824e6db..e3747f069674 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -75,22 +75,21 @@ void ttm_mem_io_free(struct ttm_device *bdev,
/**
* ttm_move_memcpy - Helper to perform a memcpy ttm move operation.
- * @bo: The struct ttm_buffer_object.
- * @new_mem: The struct ttm_resource we're moving to (copy
destination).
- * @new_iter: A struct ttm_kmap_iter representing the destination
resource.
+ * @clear: Whether to clear rather than copy.
+ * @num_pages: Number of pages of the operation.
+ * @dst_iter: A struct ttm_kmap_iter representing the destination
resource.
* @src_iter: A struct ttm_kmap_iter representing the source resource.
*
* This function is intended to be able to move out async under a
* dma-fence if desired.
*/
-void ttm_move_memcpy(struct ttm_buffer_object *bo,
+void ttm_move_memcpy(bool clear,
u32 num_pages,
struct ttm_kmap_iter *dst_iter,
struct ttm_kmap_iter *src_iter)
{
const struct ttm_kmap_iter_ops *dst_ops = dst_iter->ops;
const struct ttm_kmap_iter_ops *src_ops = src_iter->ops;
- struct ttm_tt *ttm = bo->ttm;
struct dma_buf_map src_map, dst_map;
pgoff_t i;
@@ -99,10 +98,7 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo,
return;
/* Don't move nonexistent data. Clear destination instead. */
- if (src_ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm))) {
- if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
- return;
-
+ if (clear) {
for (i = 0; i < num_pages; ++i) {
dst_ops->map_local(dst_iter, &dst_map, i);
if (dst_map.is_iomem)
@@ -146,6 +142,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
struct ttm_kmap_iter_linear_io io;
} _dst_iter, _src_iter;
struct ttm_kmap_iter *dst_iter, *src_iter;
+ bool clear;
int ret = 0;
if (ttm && ((ttm->page_flags & TTM_PAGE_FLAG_SWAPPED) ||
@@ -169,7 +166,10 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object
*bo,
goto out_src_iter;
}
- ttm_move_memcpy(bo, dst_mem->num_pages, dst_iter, src_iter);
+ clear = src_iter->ops->maps_tt && (!ttm ||
!ttm_tt_is_populated(ttm));
+ if (!(clear && ttm && !(ttm->page_flags &
TTM_PAGE_FLAG_ZERO_ALLOC)))
+ ttm_move_memcpy(clear, dst_mem->num_pages, dst_iter, src_iter);
+
src_copy = *src_mem;
ttm_bo_move_sync_cleanup(bo, dst_mem);
diff --git a/include/drm/ttm/ttm_bo_driver.h
b/include/drm/ttm/ttm_bo_driver.h
index 68d6069572aa..5f087575194b 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -322,7 +322,7 @@ int ttm_bo_tt_bind(struct ttm_buffer_object *bo,
struct ttm_resource *mem);
*/
void ttm_bo_tt_destroy(struct ttm_buffer_object *bo);
-void ttm_move_memcpy(struct ttm_buffer_object *bo,
+void ttm_move_memcpy(bool clear,
u32 num_pages,
struct ttm_kmap_iter *dst_iter,
Re: [Intel-gfx] drm/i915/ttm Initialize the ttm device and memory managers
Hi,
Static analysis with Coverity on linux-next has found a potential issue
in drivers/gpu/drm/i915/selftests/intel_memory_region.c in function
igt_mock_fill - the problematic commit is as follows:
commit d148738923fdb5077089e48ec1e6008100d0
Author: Thomas Hellström
Date: Wed Jun 2 10:38:08 2021 +0200
drm/i915/ttm Initialize the ttm device and memory managers
The analysis is as follows:
49 static int igt_mock_fill(void *arg)
50 {
51struct intel_memory_region *mem = arg;
52resource_size_t total = resource_size(&mem->region);
53resource_size_t page_size;
54resource_size_t rem;
55unsigned long max_pages;
56unsigned long page_num;
57LIST_HEAD(objects);
58int err = 0;
59
60page_size = mem->chunk_size;
61rem = total;
62 retry:
value_overwrite: Overwriting previous write to max_pages with value from
div64_u64(rem, page_size).
63max_pages = div64_u64(rem, page_size);
64
65for_each_prime_number_from(page_num, 1, max_pages) {
66resource_size_t size = page_num * page_size;
67struct drm_i915_gem_object *obj;
68
69obj = i915_gem_object_create_region(mem, size, 0);
70if (IS_ERR(obj)) {
71err = PTR_ERR(obj);
72break;
73}
74
75err = i915_gem_object_pin_pages_unlocked(obj);
76if (err) {
77i915_gem_object_put(obj);
78break;
79}
80
81list_add(&obj->st_link, &objects);
82rem -= size;
83}
84
85if (err == -ENOMEM)
86err = 0;
87if (err == -ENXIO) {
88if (page_num * page_size <= rem) {
89if (mem->is_range_manager && max_pages > 1) {
Unused value (UNUSED_VALUE)
assigned_value: Assigning value from max_pages >> 1 to max_pages here,
but that stored value is overwritten before it can be used.
90max_pages >>= 1;
91goto retry;
92}
93
The right shift to max_pages on line 90 is being overwritten on line 64
on the retry.
Colin
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
