Re: [Intel-gfx] [PATCH 3/5] mm, notifier: Catch sleeping/blocking for !blockable
On Wed, Aug 14, 2019 at 09:00:29PM -0300, Jason Gunthorpe wrote: > On Wed, Aug 14, 2019 at 10:20:25PM +0200, Daniel Vetter wrote: > > We need to make sure implementations don't cheat and don't have a > > possible schedule/blocking point deeply burried where review can't > > catch it. > > > > I'm not sure whether this is the best way to make sure all the > > might_sleep() callsites trigger, and it's a bit ugly in the code flow. > > But it gets the job done. > > > > Inspired by an i915 patch series which did exactly that, because the > > rules haven't been entirely clear to us. > > I thought lockdep already was able to detect: > > spin_lock() > might_sleep(); > spin_unlock() > > Am I mistaken? If yes, couldn't this patch just inject a dummy lockdep > spinlock? Hm ... assuming I didn't get lost in the maze I think might_sleep (well ___might_sleep) doesn't do any lockdep checking at all. And we want might_sleep, since that catches a lot more than lockdep. Maybe you mixed it up with the hard/softirq context stuff that lockdep tracks and complains about if you get it wrong? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] mm, notifier: Add a lockdep map for invalidate_range_start
On Wed, Aug 14, 2019 at 09:09:59PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 14, 2019 at 10:20:26PM +0200, Daniel Vetter wrote:
> > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > fairly easy to provoke a specific notifier to be run on a specific
> > range: Just prep it, and then munmap() it.
> >
> > A bit harder, but still doable, is to provoke the mmu notifiers for
> > all the various callchains that might lead to them. But both at the
> > same time is really hard to reliable hit, especially when you want to
> > exercise paths like direct reclaim or compaction, where it's not
> > easy to control what exactly will be unmapped.
> >
> > By introducing a lockdep map to tie them all together we allow lockdep
> > to see a lot more dependencies, without having to actually hit them
> > in a single challchain while testing.
> >
> > Aside: Since I typed this to test i915 mmu notifiers I've only rolled
> > this out for the invaliate_range_start callback. If there's
> > interest, we should probably roll this out to all of them. But my
> > undestanding of core mm is seriously lacking, and I'm not clear on
> > whether we need a lockdep map for each callback, or whether some can
> > be shared.
>
> I was thinking about doing something like this..
>
> IMHO only range_end needs annotation, the other ops are either already
> non-sleeping or only used by KVM.
This isnt' about sleeping, this is about locking loops. And the biggest
risk for that is from driver code, and at least hmm_mirror only has the
driver code callback on invalidate_range_start. Once thing I discovered
using this (and it would be really hard to spot, it's deeply neested) is
that i915 userptr.
Even if i915 userptr would use hmm_mirror (to fix the issue you mention
below), if we then switch the annotation to invalidate_range_end nothing
interesting would ever come from this. Well, the only thing it'd catch is
issues in hmm_mirror, but I think core mm review will catch that before it
reaches us :-)
> BTW, I have found it strange that i915 only uses
> invalidate_range_start. Not really sure how it is able to do
> that. Would love to know the answer :)
I suspect it's broken :-/ Our userptr is ... not the best. Part of the
motivation here.
> > Reviewed-by: Jérôme Glisse
> > Signed-off-by: Daniel Vetter
> > include/linux/mmu_notifier.h | 6 ++
> > mm/mmu_notifier.c| 7 +++
> > 2 files changed, 13 insertions(+)
> >
> > diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> > index b6c004bd9f6a..9dd38c32fc53 100644
> > +++ b/include/linux/mmu_notifier.h
> > @@ -42,6 +42,10 @@ enum mmu_notifier_event {
> >
> > #ifdef CONFIG_MMU_NOTIFIER
> >
> > +#ifdef CONFIG_LOCKDEP
> > +extern struct lockdep_map __mmu_notifier_invalidate_range_start_map;
> > +#endif
>
> I wonder what the trade off is having a global map vs a map in each
> mmu_notifier_mm ?
Less reports, specifically no reports involving multiple different mmu
notifiers to build the entire chain. But I'm assuming it's possible to
combine them in one mm (kvm+gpu+infiniband in one process sounds like
something someone could reasonably do), and it will help to make sure
everyone follows the same rules.
>
> > /*
> > * The mmu notifier_mm structure is allocated and installed in
> > * mm->mmu_notifier_mm inside the mm_take_all_locks() protected
> > @@ -310,10 +314,12 @@ static inline void mmu_notifier_change_pte(struct
> > mm_struct *mm,
> > static inline void
> > mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
> > {
> > + lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
> > if (mm_has_notifiers(range->mm)) {
> > range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE;
> > __mmu_notifier_invalidate_range_start(range);
> > }
> > + lock_map_release(&__mmu_notifier_invalidate_range_start_map);
> > }
>
> Also range_end should have this too - it has all the same
> constraints. I think it can share the map. So 'range_start_map' is
> probably not the right name.
>
> It may also make some sense to do a dummy acquire/release under the
> mm_take_all_locks() to forcibly increase map coverage and reduce the
> scenario complexity required to hit bugs.
>
> And if we do decide on the reclaim thing in my other email then the
> reclaim dependency can be reliably injected by doing:
>
> fs_reclaim_acquire();
> lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
> lock_map_release(&__mmu_notifier_invalidate_range_start_map);
> fs_reclaim_release();
>
> If I understand lockdep properly..
Ime fs_reclaim injects the mmu_notifier map here reliably as soon as
you've thrown out the first pagecache mmap on any process. That "make sure
we inject it quickly" is why the lockdep is _outside_ of the
mm_has_notifiers() check. So no further injection needed imo.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_
Re: [Intel-gfx] [PATCH 5/5] mm/hmm: WARN on illegal ->sync_cpu_device_pagetables errors
On Wed, Aug 14, 2019 at 09:11:37PM -0300, Jason Gunthorpe wrote:
> On Wed, Aug 14, 2019 at 10:20:27PM +0200, Daniel Vetter wrote:
> > Similar to the warning in the mmu notifer, warning if an hmm mirror
> > callback gets it's blocking vs. nonblocking handling wrong, or if it
> > fails with anything else than -EAGAIN.
> >
> > Cc: Jason Gunthorpe
> > Cc: Ralph Campbell
> > Cc: John Hubbard
> > Cc: Dan Williams
> > Cc: Dan Carpenter
> > Cc: Matthew Wilcox
> > Cc: Arnd Bergmann
> > Cc: Balbir Singh
> > Cc: Ira Weiny
> > Cc: Souptick Joarder
> > Cc: Andrew Morton
> > Cc: "Jérôme Glisse"
> > Cc: linux...@kvack.org
> > Signed-off-by: Daniel Vetter
> > mm/hmm.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/mm/hmm.c b/mm/hmm.c
> > index 16b6731a34db..52ac59384268 100644
> > +++ b/mm/hmm.c
> > @@ -205,6 +205,9 @@ static int hmm_invalidate_range_start(struct
> > mmu_notifier *mn,
> > ret = -EAGAIN;
> > break;
> > }
> > + WARN(ret, "%pS callback failed with %d in %sblockable
> > context\n",
> > +mirror->ops->sync_cpu_device_pagetables, ret,
> > +update.blockable ? "" : "non-");
> > }
> > up_read(&hmm->mirrors_sem);
>
> Didn't I beat you to this?
Very much possible, I think I didn't rebase this to linux-next before
resending ... have an
Reviewed-by: Daniel Vetter
in case you need.
Cheers, Daniel
>
> list_for_each_entry(mirror, &hmm->mirrors, list) {
> int rc;
>
> rc = mirror->ops->sync_cpu_device_pagetables(mirror, &update);
> if (rc) {
> if (WARN_ON(update.blockable || rc != -EAGAIN))
> continue;
> ret = -EAGAIN;
> break;
> }
> }
>
> Thanks,
> Jason
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head
On Wed, Aug 14, 2019 at 07:57:57PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-08-14 19:49:41)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > index d474c6ac4100..1ea3c3c96a5a 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > @@ -157,7 +157,15 @@ struct drm_i915_gem_object {
> > unsigned int pin_global;
> >
> > struct {
> > - struct mutex lock; /* protects the pages and their use */
> > + /*
> > +* Protects the pages and their use.
>
> "Their use" is still a misleading suggest of mine. This should be
> "protects the pinning of pages". The couple of other things it is used
> for are tied to the concept of the pages being pinned; further use should
> be discouraged; direct use prohibited.
So something like "Protects the pinning of pages. Do not use directly, but
instead go through the get/put_pages and pin/unpin interfaces." There's a
few too many of those to list them all imo ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] RFC: drm/i915: Switch obj->mm.lock lockdep annotations on its head
Quoting Daniel Vetter (2019-08-15 08:23:01)
> On Wed, Aug 14, 2019 at 07:57:57PM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-08-14 19:49:41)
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > index d474c6ac4100..1ea3c3c96a5a 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > @@ -157,7 +157,15 @@ struct drm_i915_gem_object {
> > > unsigned int pin_global;
> > >
> > > struct {
> > > - struct mutex lock; /* protects the pages and their use */
> > > + /*
> > > +* Protects the pages and their use.
> >
> > "Their use" is still a misleading suggest of mine. This should be
> > "protects the pinning of pages". The couple of other things it is used
> > for are tied to the concept of the pages being pinned; further use should
> > be discouraged; direct use prohibited.
>
> So something like "Protects the pinning of pages. Do not use directly, but
> instead go through the get/put_pages and pin/unpin interfaces." There's a
> few too many of those to list them all imo ...
I would say only pin/unpin. get/put is the for implementation.
Fwiw, elsewhere we adopted the name pin_mutex / pin_count. But there's
also variations on that naming scheme. The pattern of "that who is being
pinned may unpin others" is repeating.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Restore seqlock around dma_resv updates
Am 14.08.19 um 20:26 schrieb Chris Wilson:
> Quoting Chris Wilson (2019-08-14 19:24:01)
>> This reverts
>> 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
>> dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
>> 0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence")
>> 5d344f58da76 ("dma-buf: nuke reservation_object seq number")
>>
>> The scenario that defeats simply grabbing a set of shared/exclusive
>> fences and using them blissfully under RCU is that any of those fences
>> may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this
>> scenario, while keeping the rcu_read_lock we need to establish that no
>> fence was changed in the dma_resv after a read (or full) memory barrier.
>>
>> Signed-off-by: Chris Wilson
Acked-by: Christian König
>> Cc: Chris Wilson
> I said I needed to go lie down, that proves it.
>
> Cc: Christian König
>
>> Cc: Daniel Vetter
>> ---
>> drivers/dma-buf/dma-buf.c | 31 -
>> drivers/dma-buf/dma-resv.c| 109 -
>> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 +-
>> drivers/gpu/drm/i915/gem/i915_gem_busy.c | 24 ++--
>> include/linux/dma-resv.h | 113 --
>> 5 files changed, 175 insertions(+), 109 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index b3400d6524ab..433d91d710e4 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -199,7 +199,7 @@ static __poll_t dma_buf_poll(struct file *file,
>> poll_table *poll)
>> struct dma_resv_list *fobj;
>> struct dma_fence *fence_excl;
>> __poll_t events;
>> - unsigned shared_count;
>> + unsigned shared_count, seq;
>>
>> dmabuf = file->private_data;
>> if (!dmabuf || !dmabuf->resv)
>> @@ -213,8 +213,21 @@ static __poll_t dma_buf_poll(struct file *file,
>> poll_table *poll)
>> if (!events)
>> return 0;
>>
>> +retry:
>> + seq = read_seqcount_begin(&resv->seq);
>> rcu_read_lock();
>> - dma_resv_fences(resv, &fence_excl, &fobj, &shared_count);
>> +
>> + fobj = rcu_dereference(resv->fence);
>> + if (fobj)
>> + shared_count = fobj->shared_count;
>> + else
>> + shared_count = 0;
>> + fence_excl = rcu_dereference(resv->fence_excl);
>> + if (read_seqcount_retry(&resv->seq, seq)) {
>> + rcu_read_unlock();
>> + goto retry;
>> + }
>> +
>> if (fence_excl && (!(events & EPOLLOUT) || shared_count == 0)) {
>> struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_excl;
>> __poll_t pevents = EPOLLIN;
>> @@ -1144,6 +1157,7 @@ static int dma_buf_debug_show(struct seq_file *s, void
>> *unused)
>> struct dma_resv *robj;
>> struct dma_resv_list *fobj;
>> struct dma_fence *fence;
>> + unsigned seq;
>> int count = 0, attach_count, shared_count, i;
>> size_t size = 0;
>>
>> @@ -1174,9 +1188,16 @@ static int dma_buf_debug_show(struct seq_file *s,
>> void *unused)
>> buf_obj->name ?: "");
>>
>> robj = buf_obj->resv;
>> - rcu_read_lock();
>> - dma_resv_fences(robj, &fence, &fobj, &shared_count);
>> - rcu_read_unlock();
>> + while (true) {
>> + seq = read_seqcount_begin(&robj->seq);
>> + rcu_read_lock();
>> + fobj = rcu_dereference(robj->fence);
>> + shared_count = fobj ? fobj->shared_count : 0;
>> + fence = rcu_dereference(robj->fence_excl);
>> + if (!read_seqcount_retry(&robj->seq, seq))
>> + break;
>> + rcu_read_unlock();
>> + }
>>
>> if (fence)
>> seq_printf(s, "\tExclusive fence: %s %s
>> %ssignalled\n",
>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
>> index f5142683c851..42a8f3f11681 100644
>> --- a/drivers/dma-buf/dma-resv.c
>> +++ b/drivers/dma-buf/dma-resv.c
>> @@ -49,6 +49,12 @@
>> DEFINE_WD_CLASS(reservation_ww_class);
>> EXPORT_SYMBOL(reservation_ww_class);
>>
>> +struct lock_class_key reservation_seqcount_class;
>> +EXPORT_SYMBOL(reservation_seqcount_class);
>> +
>> +const char reservation_seqcount_string[] = "reservation_seqcount";
>> +EXPORT_SYMBOL(reservation_seqcount_string);
>> +
>> /**
>>* dma_resv_list_alloc - allocate fence list
>>* @shared_max: number of fences we need space for
>> @@ -96,6 +102,9 @@ static void dma_resv_list_free(struct dma_resv_list *list)
>> void dma_resv_init(struct dma_resv *obj)
>> {
>> ww_mutex_init(&obj->lock, &reservation_ww_class);
>> +
>> + __seqcount_init(&obj->seq, reserv
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT
== Series Details == Series: drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT URL : https://patchwork.freedesktop.org/series/65222/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6711 -> Patchwork_14023 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14023 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14023, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14023: ### IGT changes ### Possible regressions * igt@gem_exec_gttfill@basic: - fi-blb-e6850: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-blb-e6850/igt@gem_exec_gttf...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-blb-e6850/igt@gem_exec_gttf...@basic.html - fi-elk-e7500: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-elk-e7500/igt@gem_exec_gttf...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-elk-e7500/igt@gem_exec_gttf...@basic.html - fi-ilk-650: [PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-ilk-650/igt@gem_exec_gttf...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-ilk-650/igt@gem_exec_gttf...@basic.html * igt@runner@aborted: - fi-ilk-650: NOTRUN -> [FAIL][7] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-ilk-650/igt@run...@aborted.html - fi-blb-e6850: NOTRUN -> [FAIL][8] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-blb-e6850/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_14023 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@basic-write-cpu-read-gtt: - fi-icl-u3: [PASS][9] -> [DMESG-WARN][10] ([fdo#107724]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-icl-u3/igt@gem_mmap_...@basic-write-cpu-read-gtt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-icl-u3/igt@gem_mmap_...@basic-write-cpu-read-gtt.html * igt@i915_selftest@live_execlists: - fi-skl-gvtdvm: [PASS][11] -> [DMESG-FAIL][12] ([fdo#08]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html * igt@i915_selftest@live_requests: - fi-byt-j1900: [PASS][13] -> [INCOMPLETE][14] ([fdo#102657]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-byt-j1900/igt@i915_selftest@live_requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-byt-j1900/igt@i915_selftest@live_requests.html * igt@kms_busy@basic-flip-c: - fi-skl-6770hq: [PASS][15] -> [SKIP][16] ([fdo#109271] / [fdo#109278]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html * igt@kms_chamelium@hdmi-crc-fast: - fi-icl-u2: [PASS][17] -> [FAIL][18] ([fdo#109635 ]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_flip@basic-flip-vs-dpms: - fi-skl-6770hq: [PASS][19] -> [SKIP][20] ([fdo#109271]) +23 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html Possible fixes * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: [SKIP][21] ([fdo#109271] / [fdo#109278]) -> [PASS][22] +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html * igt@kms_chamelium@dp-crc-fast: - fi-cml-u2: [FAIL][23] ([fdo#110387]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14023/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel - One use after free fix for GVT. It doesn't have a Link: tag because dim doesn't check that while applying the pull, and, for some reason, it was also not checked when I pushed out the branch. Possibly because it's in a merge? Anyway, I only got the complaint when making the pull request, which is too late. drm-intel-fixes-2019-08-15: drm/i915 fixes for v5.4-rc5: - GVT use-after-free fix BR, Jani. The following changes since commit d45331b00ddb179e291766617259261c112db872: Linux 5.3-rc4 (2019-08-11 13:26:41 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-08-15 for you to fetch changes up to daa37200d48906d71c63ce178bf7d410b7e07082: Merge tag 'gvt-fixes-2019-08-13' of https://github.com/intel/gvt-linux into drm-intel-fixes (2019-08-13 16:26:34 +0300) drm/i915 fixes for v5.4-rc5: - GVT use-after-free fix Dan Carpenter (1): drm/i915: Use after free in error path in intel_vgpu_create_workload() Jani Nikula (1): Merge tag 'gvt-fixes-2019-08-13' of https://github.com/intel/gvt-linux into drm-intel-fixes drivers/gpu/drm/i915/gvt/scheduler.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT
When under severe stress for GTT mappable space, the LRU eviction model
falls off a cliff. We spend all our time scanning the much large
non-mappable vma searching for something within the mappable zone we can
evict. Turn this on its head by only using the full vma if it is already
pinned in the mappable zone or there is sufficient *free* space to
accommodate it(prioritizing speedy reuse). If there is not, immediately
fall back to using small chunks (tilerow for GTT mmap, single pages for
pwrite/relocation) and using random eviction before doing a full search.
Testcase: igt/gem_concurrent_blt
References: https://bugs.freedesktop.org/show_bug.cgi?id=110848
Signed-off-by: Chris Wilson
---
Keep nonblock around, it serves as a NOWARN flag for the full pin.
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 8
drivers/gpu/drm/i915/i915_gem.c| 8
drivers/gpu/drm/i915/i915_gem_evict.c | 8
drivers/gpu/drm/i915/i915_gem_gtt.c| 6 +-
drivers/gpu/drm/i915/i915_gem_gtt.h| 6 +++---
6 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 91512cc6d7a6..669f8e2fffeb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1092,8 +1092,8 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONBLOCK |
- PIN_NONFAULT);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
if (IS_ERR(vma)) {
memset(&cache->node, 0, sizeof(cache->node));
err = drm_mm_insert_node_in_range
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 1e7311493530..495ff681647b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -267,15 +267,15 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
/* Now pin it into the GTT as needed */
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONBLOCK |
- PIN_NONFAULT);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOSEARCH);
if (IS_ERR(vma)) {
/* Use a partial view if it is bigger than available space */
struct i915_ggtt_view view =
compute_partial_view(obj, page_offset, MIN_CHUNK_PAGES);
unsigned int flags;
- flags = PIN_MAPPABLE;
+ flags = PIN_MAPPABLE | PIN_NOSEARCH;
if (view.type == I915_GGTT_VIEW_NORMAL)
flags |= PIN_NONBLOCK; /* avoid warnings for pinned */
@@ -286,7 +286,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
obj->frontbuffer_ggtt_origin = ORIGIN_CPU;
vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
- if (IS_ERR(vma) && !view.type) {
+ if (IS_ERR(vma)) {
flags = PIN_MAPPABLE;
view.type = I915_GGTT_VIEW_PARTIAL;
vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b4c39a06fee5..c57094471232 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -343,8 +343,8 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
wakeref = intel_runtime_pm_get(&i915->runtime_pm);
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONFAULT |
- PIN_NONBLOCK);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
if (!IS_ERR(vma)) {
node.start = i915_ggtt_offset(vma);
node.allocated = false;
@@ -557,8 +557,8 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj,
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONFAULT |
- PIN_NONBLOCK);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
if (!IS_ERR(vma)) {
node.start = i915_ggtt_offs
Re: [Intel-gfx] [v7][PATCH 00/12] drm/i915: adding state checker for gamma lut values
On Wed, 29 May 2019, Swati Sharma wrote: > In this patch series, added state checker to validate gamma > and will be extended to validate degamma lut values aswell. > This reads hardware state, and compares the originally > requested state to the state read from hardware. What happened to this patch series? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/icl: Implement gen11 flush including tile cache
Add tile cache flushing for gen11. To relive us from the
burden of previous obsolete workarounds, make a dedicated
flush/invalidate callback for gen11.
To fortify an independent single flush, do post
sync op as there are indications that without it
we don't flush everything. This should also make this
callback more readily usable in tgl (see l3 fabric flush).
v2: whitespacing
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 61 +++-
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 6a0879c27d14..929a17e54f2c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -208,6 +208,7 @@
#define DISPLAY_PLANE_A (0<<20)
#define DISPLAY_PLANE_B (1<<20)
#define GFX_OP_PIPE_CONTROL(len)
((0x3<<29)|(0x3<<27)|(0x2<<24)|((len)-2))
+#define PIPE_CONTROL_TILE_CACHE_FLUSH(1<<28) /*
gen11+ */
#define PIPE_CONTROL_FLUSH_L3(1<<27)
#define PIPE_CONTROL_GLOBAL_GTT_IVB (1<<24) /* gen7+ */
#define PIPE_CONTROL_MMIO_WRITE (1<<23)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 5c26c4ae139b..6a27a897d7a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2655,6 +2655,62 @@ static int gen8_emit_flush_render(struct i915_request
*request,
return 0;
}
+static int gen11_emit_flush_render(struct i915_request *request,
+ u32 mode)
+{
+ struct intel_engine_cs *engine = request->engine;
+ const u32 scratch_addr =
+ intel_gt_scratch_offset(engine->gt,
+ INTEL_GT_SCRATCH_FIELD_RENDER_FLUSH);
+
+ if (mode & EMIT_FLUSH) {
+ u32 *cs;
+ u32 flags = 0;
+
+ flags |= PIPE_CONTROL_CS_STALL;
+
+ flags |= PIPE_CONTROL_TILE_CACHE_FLUSH;
+ flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+ flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+ flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
+ flags |= PIPE_CONTROL_FLUSH_ENABLE;
+ flags |= PIPE_CONTROL_QW_WRITE;
+ flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
+
+ cs = intel_ring_begin(request, 6);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ cs = gen8_emit_pipe_control(cs, flags, scratch_addr);
+ intel_ring_advance(request, cs);
+ }
+
+ if (mode & EMIT_INVALIDATE) {
+ u32 *cs;
+ u32 flags = 0;
+
+ flags |= PIPE_CONTROL_CS_STALL;
+
+ flags |= PIPE_CONTROL_TLB_INVALIDATE;
+ flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_QW_WRITE;
+ flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
+
+ cs = intel_ring_begin(request, 6);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ cs = gen8_emit_pipe_control(cs, flags, scratch_addr);
+ intel_ring_advance(request, cs);
+ }
+
+ return 0;
+}
+
/*
* Reserve space for 2 NOOPs at the end of each request to be
* used as a workaround for not being allowed to do lite
@@ -2829,7 +2885,10 @@ int intel_execlists_submission_setup(struct
intel_engine_cs *engine)
logical_ring_default_irqs(engine);
if (engine->class == RENDER_CLASS) {
- engine->emit_flush = gen8_emit_flush_render;
+ if (INTEL_GEN(engine->i915) >= 11)
+ engine->emit_flush = gen11_emit_flush_render;
+ else
+ engine->emit_flush = gen8_emit_flush_render;
engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb_rcs;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/icl: Add gen11 specific render breadcrumbs
Flush according to what gen11 expects when writing
breadcrumbs. As only the seqnowrite + flush differs
between engine and gens, enclose the footer to
helper.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 88 -
1 file changed, 62 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 9018afb4e9ef..de84febdec43 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2740,12 +2740,10 @@ static u32 *emit_preempt_busywait(struct i915_request
*request, u32 *cs)
return cs;
}
-static u32 *gen8_emit_fini_breadcrumb(struct i915_request *request, u32 *cs)
+static __always_inline u32*
+gen8_emit_fini_breadcrumb_footer(struct i915_request *request,
+u32 *cs)
{
- cs = gen8_emit_ggtt_write(cs,
- request->fence.seqno,
- request->timeline->hwsp_offset,
- 0);
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
@@ -2758,29 +2756,55 @@ static u32 *gen8_emit_fini_breadcrumb(struct
i915_request *request, u32 *cs)
return gen8_emit_wa_tail(request, cs);
}
+static u32 *gen8_emit_fini_breadcrumb(struct i915_request *request, u32 *cs)
+{
+ cs = gen8_emit_ggtt_write(cs,
+ request->fence.seqno,
+ request->timeline->hwsp_offset,
+ 0);
+
+ return gen8_emit_fini_breadcrumb_footer(request, cs);
+}
+
static u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *request, u32
*cs)
{
+ const u32 pipectl_first =
+ PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+ PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+ PIPE_CONTROL_DC_FLUSH_ENABLE;
+
/* XXX flush+write+CS_STALL all in one upsets gem_concurrent_blt:kbl */
+ const u32 pipectl_second =
+ PIPE_CONTROL_FLUSH_ENABLE |
+ PIPE_CONTROL_CS_STALL;
+
cs = gen8_emit_ggtt_write_rcs(cs,
request->fence.seqno,
request->timeline->hwsp_offset,
- PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
- PIPE_CONTROL_DEPTH_CACHE_FLUSH |
- PIPE_CONTROL_DC_FLUSH_ENABLE);
- cs = gen8_emit_pipe_control(cs,
- PIPE_CONTROL_FLUSH_ENABLE |
- PIPE_CONTROL_CS_STALL,
- 0);
- *cs++ = MI_USER_INTERRUPT;
+ pipectl_first);
- *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
- if (intel_engine_has_semaphores(request->engine))
- cs = emit_preempt_busywait(request, cs);
+ cs = gen8_emit_pipe_control(cs, pipectl_second, 0);
- request->tail = intel_ring_offset(request, cs);
- assert_ring_tail_valid(request->ring, request->tail);
+ return gen8_emit_fini_breadcrumb_footer(request, cs);
+}
- return gen8_emit_wa_tail(request, cs);
+static u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request *request,
+ u32 *cs)
+{
+ const u32 pipectl =
+ PIPE_CONTROL_CS_STALL |
+ PIPE_CONTROL_TILE_CACHE_FLUSH |
+ PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+ PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+ PIPE_CONTROL_DC_FLUSH_ENABLE |
+ PIPE_CONTROL_FLUSH_ENABLE;
+
+ cs = gen8_emit_ggtt_write_rcs(cs,
+ request->fence.seqno,
+ request->timeline->hwsp_offset,
+ pipectl);
+
+ return gen8_emit_fini_breadcrumb_footer(request, cs);
}
static void execlists_park(struct intel_engine_cs *engine)
@@ -2876,6 +2900,23 @@ logical_ring_default_irqs(struct intel_engine_cs *engine)
engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift;
}
+static void rcs_submission_override(struct intel_engine_cs *engine)
+{
+ switch (INTEL_GEN(engine->i915)) {
+
+ case 12:
+ case 11:
+ engine->emit_flush = gen11_emit_flush_render;
+ engine->emit_fini_breadcrumb = gen11_emit_fini_breadcrumb_rcs;
+ break;
+
+ default:
+ engine->emit_flush = gen8_emit_flush_render;
+ engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb_rcs;
+ break;
+ }
+}
+
int intel_execlists_submission_setup(struct intel_engine_cs *engine)
{
tasklet_init(&engine->execlists.tasklet,
@@ -2885,13 +2926,8 @@ int intel_execlists_submission_setup(struct
intel_engine_cs *engine)
logical_ring_default_vfuncs(engin
[Intel-gfx] [PATCH 2/3] drm/i915/icl: Add command cache invalidate
On the set of invalidations, we need to add command cache invalidate as a new domain. Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h index 929a17e54f2c..86e00a2db8a4 100644 --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h @@ -208,6 +208,7 @@ #define DISPLAY_PLANE_A (0<<20) #define DISPLAY_PLANE_B (1<<20) #define GFX_OP_PIPE_CONTROL(len) ((0x3<<29)|(0x3<<27)|(0x2<<24)|((len)-2)) +#define PIPE_CONTROL_COMMAND_CACHE_INVALIDATE(1<<29) /* gen11+ */ #define PIPE_CONTROL_TILE_CACHE_FLUSH(1<<28) /* gen11+ */ #define PIPE_CONTROL_FLUSH_L3(1<<27) #define PIPE_CONTROL_GLOBAL_GTT_IVB (1<<24) /* gen7+ */ diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 6a27a897d7a6..9018afb4e9ef 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -2691,6 +2691,7 @@ static int gen11_emit_flush_render(struct i915_request *request, flags |= PIPE_CONTROL_CS_STALL; + flags |= PIPE_CONTROL_COMMAND_CACHE_INVALIDATE; flags |= PIPE_CONTROL_TLB_INVALIDATE; flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE; flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/tgl: Fix TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT() macro
This macro doesn't work because the right shift has higher precedence
than bitwise AND.
Fixes: 9749a5b6c09f ("drm/i915/tgl: Fix the read of the DDI that transcoder is
attached to")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4a947bd0a294..def6dbdc7e2e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9433,7 +9433,7 @@ enum skl_power_gate {
#define TRANS_DDI_SELECT_PORT(x) ((x) << TRANS_DDI_PORT_SHIFT)
#define TGL_TRANS_DDI_SELECT_PORT(x) (((x) + 1) << TGL_TRANS_DDI_PORT_SHIFT)
#define TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val)(((val) & TRANS_DDI_PORT_MASK)
>> TRANS_DDI_PORT_SHIFT)
-#define TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val) (((val) &
TGL_TRANS_DDI_PORT_MASK >> TGL_TRANS_DDI_PORT_SHIFT) - 1)
+#define TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val) val) &
TGL_TRANS_DDI_PORT_MASK) >> TGL_TRANS_DDI_PORT_SHIFT) - 1)
#define TRANS_DDI_MODE_SELECT_MASK(7 << 24)
#define TRANS_DDI_MODE_SELECT_HDMI(0 << 24)
#define TRANS_DDI_MODE_SELECT_DVI (1 << 24)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v14 13/33] drm/i915: Implement the HDCP2.2 support for DP
On Sat, 16 Feb 2019, Ramalingam C via dri-devel
wrote:
> Implements the DP adaptation specific HDCP2.2 functions.
>
> These functions perform the DPCD read and write for communicating the
> HDCP2.2 auth message back and forth.
>
> v2:
> wait for cp_irq is merged with this patch. Rebased.
> v3:
> wait_queue is used for wait for cp_irq [Chris Wilson]
> v4:
> Style fixed.
> %s/PARING/PAIRING
> Few style fixes [Uma]
> v5:
> Lookup table for DP HDCP2.2 msg details [Daniel].
> Extra lines are removed.
> v6: Rebased.
> v7:
> Fixed some regression introduced at v5. [Ankit]
> Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma]
> Converted a function to inline [Uma]
> %s/uintxx_t/uxx
> v8:
> Error due to the sinks are reported as DEBUG logs.
> Adjust to the new mei interface.
> v9:
> ARRAY_SIZE for no of array members [Jon & Daniel]
> return of the wait_for_cp_irq is made as void [Daniel]
> Wait for HDCP2.2 msg is done based on polling the reg bit than
> CP_IRQ based. [Daniel]
> hdcp adaptation is added as a const in the hdcp_shim [Daniel]
> v10:
> config_stream_type is redefined [Daniel]
> DP Errata specific defines are moved into intel_dp.c.
>
> Signed-off-by: Ramalingam C
> Signed-off-by: Ankit K Nautiyal
> Reviewed-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/intel_dp.c | 333
>
> 1 file changed, 333 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9f73a4239574..e9fe25f21200 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5847,6 +5847,333 @@ int intel_dp_hdcp_capable(struct intel_digital_port
> *intel_dig_port,
> return 0;
> }
>
> +struct hdcp2_dp_errata_stream_type {
> + u8 msg_id;
> + u8 stream_type;
> +} __packed;
> +
> +static struct hdcp2_dp_msg_data {
> + u8 msg_id;
> + u32 offset;
> + bool msg_detectable;
> + u32 timeout;
> + u32 timeout2; /* Added for non_paired situation */
> + } hdcp2_msg_data[] = {
> + {HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0},
> + {HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
> + false, HDCP_2_2_CERT_TIMEOUT_MS, 0},
> + {HDCP_2_2_AKE_NO_STORED_KM, DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
> + false, 0, 0},
> + {HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
> + false, 0, 0},
> + {HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
> + true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
> + HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
> + {HDCP_2_2_AKE_SEND_PAIRING_INFO,
> + DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, true,
> + HDCP_2_2_PAIRING_TIMEOUT_MS, 0},
> + {HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0},
> + {HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
> + false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0},
> + {HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, false,
> + 0, 0},
> + {HDCP_2_2_REP_SEND_RECVID_LIST,
> + DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
> + HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
> + {HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, false,
> + 0, 0},
> + {HDCP_2_2_REP_STREAM_MANAGE,
> + DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
> + 0, 0},
> + {HDCP_2_2_REP_STREAM_READY, DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
> + false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0},
> +/* local define to shovel this through the write_2_2 interface */
> +#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
> + {HDCP_2_2_ERRATA_DP_STREAM_TYPE,
> + DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET, false,
> + 0, 0},
> + };
Hate to bring this up so far after this has been merged, but
hdcp2_msg_data[] must be moved out of driver static data.
BR,
Jani.
> +
> +static inline
> +int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
> + u8 *rx_status)
> +{
> + ssize_t ret;
> +
> + ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux,
> +DP_HDCP_2_2_REG_RXSTATUS_OFFSET, rx_status,
> +HDCP_2_2_DP_RXSTATUS_LEN);
> + if (ret != HDCP_2_2_DP_RXSTATUS_LEN) {
> + DRM_DEBUG_KMS("Read bstatus from DP/AUX failed (%zd)\n", ret);
> + return ret >= 0 ? -EIO : ret;
> + }
> +
> + return 0;
> +}
> +
> +static
> +int hdcp2_detect_msg_av
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Wed 14-08-19 13:45:58, Andrew Morton wrote: > On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter > wrote: > > > In some special cases we must not block, but there's not a > > spinlock, preempt-off, irqs-off or similar critical section already > > that arms the might_sleep() debug checks. Add a non_block_start/end() > > pair to annotate these. > > > > This will be used in the oom paths of mmu-notifiers, where blocking is > > not allowed to make sure there's forward progress. Quoting Michal: > > > > "The notifier is called from quite a restricted context - oom_reaper - > > which shouldn't depend on any locks or sleepable conditionals. The code > > should be swift as well but we mostly do care about it to make a forward > > progress. Checking for sleepable context is the best thing we could come > > up with that would describe these demands at least partially." > > > > Peter also asked whether we want to catch spinlocks on top, but Michal > > said those are less of a problem because spinlocks can't have an > > indirect dependency upon the page allocator and hence close the loop > > with the oom reaper. > > I continue to struggle with this. It introduces a new kernel state > "running preemptibly but must not call schedule()". How does this make > any sense? > > Perhaps a much, much more detailed description of the oom_reaper > situation would help out. The primary point here is that there is a demand of non blockable mmu notifiers to be called when the oom reaper tears down the address space. As the oom reaper is the primary guarantee of the oom handling forward progress it cannot be blocked on anything that might depend on blockable memory allocations. These are not really easy to track because they might be indirect - e.g. notifier blocks on a lock which other context holds while allocating memory or waiting for a flusher that needs memory to perform its work. If such a blocking state happens that we can end up in a silent hang with an unusable machine. Now we hope for reasonable implementations of mmu notifiers (strong words I know ;) and this should be relatively simple and effective catch all tool to detect something suspicious is going on. Does that make the situation more clear? -- Michal Hocko SUSE Labs ___ 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/3] drm/i915/icl: Implement gen11 flush including tile cache
== Series Details ==
Series: series starting with [1/3] drm/i915/icl: Implement gen11 flush
including tile cache
URL : https://patchwork.freedesktop.org/series/65226/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4241b319406b drm/i915/icl: Implement gen11 flush including tile cache
-:29: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#29: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:211:
+#define PIPE_CONTROL_TILE_CACHE_FLUSH(1<<28) /*
gen11+ */
^
total: 0 errors, 0 warnings, 1 checks, 80 lines checked
302da876b5c3 drm/i915/icl: Add command cache invalidate
-:20: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#20: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:211:
+#define PIPE_CONTROL_COMMAND_CACHE_INVALIDATE(1<<29) /*
gen11+ */
^
total: 0 errors, 0 warnings, 1 checks, 14 lines checked
ae616484b0f1 drm/i915/icl: Add gen11 specific render breadcrumbs
-:111: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#111: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2906:
+ switch (INTEL_GEN(engine->i915)) {
+
total: 0 errors, 0 warnings, 1 checks, 122 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [bug report] drm/i915: buddy allocator
Hello Matthew Auld,
The patch 14d1b9a6247c: "drm/i915: buddy allocator" from Aug 9, 2019,
leads to the following static checker warning:
drivers/gpu/drm/i915/selftests/i915_buddy.c:670 igt_buddy_alloc_range()
error: we previously assumed 'block' could be null (see line 665)
drivers/gpu/drm/i915/selftests/i915_buddy.c
660 }
661
662 block = list_first_entry_or_null(&tmp,
663 struct
i915_buddy_block,
664 link);
665 if (!block) {
666 pr_err("alloc_range has no blocks\n");
667 err = -EINVAL;
No break statement?
668 }
669
670 if (i915_buddy_block_offset(block) != offset) {
671 pr_err("alloc_range start offset mismatch,
found=%llx, expected=%llx\n",
672 i915_buddy_block_offset(block), offset);
673 err = -EINVAL;
I guess we still want to splice this into the list even though it's
invalid?
674 }
675
676 if (!err)
677 err = igt_check_blocks(&mm, &tmp, size, true);
Same
678
679 list_splice_tail(&tmp, &blocks);
680
681 if (err)
682 break;
683
684 offset += size;
685
686 rem -= size;
regards,
dan carpenter
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/tgl: Fix TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT() macro
== Series Details == Series: drm/i915/tgl: Fix TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT() macro URL : https://patchwork.freedesktop.org/series/65227/ State : failure == Summary == Applying: drm/i915/tgl: Fix TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT() macro Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_reg.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_reg.h No changes -- Patch already applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT (rev2)
== Series Details ==
Series: drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT (rev2)
URL : https://patchwork.freedesktop.org/series/65222/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6711 -> Patchwork_14024
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/
Known issues
Here are the changes found in Patchwork_14024 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_basic@create-close:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-icl-u3/igt@gem_ba...@create-close.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/fi-icl-u3/igt@gem_ba...@create-close.html
* igt@kms_busy@basic-flip-c:
- fi-skl-6770hq: [PASS][3] -> [SKIP][4] ([fdo#109271] / [fdo#109278])
+2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq: [PASS][5] -> [SKIP][6] ([fdo#109271]) +23 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
Possible fixes
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [SKIP][7] ([fdo#109271] / [fdo#109278]) -> [PASS][8]
+2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [FAIL][9] ([fdo#110387]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
Participating hosts (53 -> 46)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6711 -> Patchwork_14024
CI-20190529: 20190529
CI_DRM_6711: 66992026e64fe4405ca25b1e978a98c7e132673b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14024: ec652122770b1e5ebfcf1c55de31d501f38a2552 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ec652122770b drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14024/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/icl: Add gen11 specific render breadcrumbs
Quoting Mika Kuoppala (2019-08-15 09:30:55)
> Flush according to what gen11 expects when writing
> breadcrumbs. As only the seqnowrite + flush differs
> between engine and gens, enclose the footer to
> helper.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 88 -
> 1 file changed, 62 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 9018afb4e9ef..de84febdec43 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2740,12 +2740,10 @@ static u32 *emit_preempt_busywait(struct i915_request
> *request, u32 *cs)
> return cs;
> }
>
> -static u32 *gen8_emit_fini_breadcrumb(struct i915_request *request, u32 *cs)
> +static __always_inline u32*
> +gen8_emit_fini_breadcrumb_footer(struct i915_request *request,
> +u32 *cs)
> {
> - cs = gen8_emit_ggtt_write(cs,
> - request->fence.seqno,
> - request->timeline->hwsp_offset,
> - 0);
> *cs++ = MI_USER_INTERRUPT;
>
> *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
> @@ -2758,29 +2756,55 @@ static u32 *gen8_emit_fini_breadcrumb(struct
> i915_request *request, u32 *cs)
> return gen8_emit_wa_tail(request, cs);
> }
>
> +static u32 *gen8_emit_fini_breadcrumb(struct i915_request *request, u32 *cs)
> +{
> + cs = gen8_emit_ggtt_write(cs,
> + request->fence.seqno,
> + request->timeline->hwsp_offset,
> + 0);
> +
> + return gen8_emit_fini_breadcrumb_footer(request, cs);
> +}
> +
> static u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *request, u32
> *cs)
> {
> + const u32 pipectl_first =
> + PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
> + PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> + PIPE_CONTROL_DC_FLUSH_ENABLE;
We weren't overflowing, it didn't look too bad to have the constants
inline.
> +
> /* XXX flush+write+CS_STALL all in one upsets gem_concurrent_blt:kbl
> */
> + const u32 pipectl_second =
> + PIPE_CONTROL_FLUSH_ENABLE |
> + PIPE_CONTROL_CS_STALL;
> +
> cs = gen8_emit_ggtt_write_rcs(cs,
> request->fence.seqno,
> request->timeline->hwsp_offset,
> - PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
> - PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> - PIPE_CONTROL_DC_FLUSH_ENABLE);
> - cs = gen8_emit_pipe_control(cs,
> - PIPE_CONTROL_FLUSH_ENABLE |
> - PIPE_CONTROL_CS_STALL,
> - 0);
> - *cs++ = MI_USER_INTERRUPT;
> + pipectl_first);
>
> - *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
> - if (intel_engine_has_semaphores(request->engine))
> - cs = emit_preempt_busywait(request, cs);
> + cs = gen8_emit_pipe_control(cs, pipectl_second, 0);
>
> - request->tail = intel_ring_offset(request, cs);
> - assert_ring_tail_valid(request->ring, request->tail);
> + return gen8_emit_fini_breadcrumb_footer(request, cs);
> +}
>
> - return gen8_emit_wa_tail(request, cs);
> +static u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request *request,
> + u32 *cs)
> +{
> + const u32 pipectl =
> + PIPE_CONTROL_CS_STALL |
> + PIPE_CONTROL_TILE_CACHE_FLUSH |
> + PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
> + PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> + PIPE_CONTROL_DC_FLUSH_ENABLE |
> + PIPE_CONTROL_FLUSH_ENABLE;
> +
> + cs = gen8_emit_ggtt_write_rcs(cs,
> + request->fence.seqno,
> + request->timeline->hwsp_offset,
> + pipectl);
> +
> + return gen8_emit_fini_breadcrumb_footer(request, cs);
> }
>
> static void execlists_park(struct intel_engine_cs *engine)
> @@ -2876,6 +2900,23 @@ logical_ring_default_irqs(struct intel_engine_cs
> *engine)
> engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift;
> }
>
> +static void rcs_submission_override(struct intel_engine_cs *engine)
> +{
> + switch (INTEL_GEN(engine->i915)) {
> +
Bonus \n!
With the choice of placement for the constants justified one way or the
other (I ask not for pipectl_the_second :)
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Fix TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT() macro
On Thu, 15 Aug 2019, Dan Carpenter wrote:
> This macro doesn't work because the right shift has higher precedence
> than bitwise AND.
>
> Fixes: 9749a5b6c09f ("drm/i915/tgl: Fix the read of the DDI that transcoder
> is attached to")
> Signed-off-by: Dan Carpenter
Thanks, already fixed by 1cdd8705c7ac ("drm/i915/tgl: Fix missing
parentheses on TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT").
BR,
Jani.
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 4a947bd0a294..def6dbdc7e2e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9433,7 +9433,7 @@ enum skl_power_gate {
> #define TRANS_DDI_SELECT_PORT(x)((x) << TRANS_DDI_PORT_SHIFT)
> #define TGL_TRANS_DDI_SELECT_PORT(x)(((x) + 1) <<
> TGL_TRANS_DDI_PORT_SHIFT)
> #define TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val) (((val) & TRANS_DDI_PORT_MASK)
> >> TRANS_DDI_PORT_SHIFT)
> -#define TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val) (((val) &
> TGL_TRANS_DDI_PORT_MASK >> TGL_TRANS_DDI_PORT_SHIFT) - 1)
> +#define TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val) val) &
> TGL_TRANS_DDI_PORT_MASK) >> TGL_TRANS_DDI_PORT_SHIFT) - 1)
> #define TRANS_DDI_MODE_SELECT_MASK (7 << 24)
> #define TRANS_DDI_MODE_SELECT_HDMI (0 << 24)
> #define TRANS_DDI_MODE_SELECT_DVI (1 << 24)
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/icl: Implement gen11 flush including tile cache
Quoting Mika Kuoppala (2019-08-15 09:30:53) > Add tile cache flushing for gen11. To relive us from the > burden of previous obsolete workarounds, make a dedicated > flush/invalidate callback for gen11. > > To fortify an independent single flush, do post > sync op as there are indications that without it > we don't flush everything. This should also make this > callback more readily usable in tgl (see l3 fabric flush). > > v2: whitespacing > > Cc: Chris Wilson > Cc: Daniele Ceraolo Spurio > Signed-off-by: Mika Kuoppala The bits match to bspec, so going by name alone, Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache
== Series Details == Series: series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache URL : https://patchwork.freedesktop.org/series/65226/ State : success == Summary == CI Bug Log - changes from CI_DRM_6711 -> Patchwork_14025 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/ Known issues Here are the changes found in Patchwork_14025 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_create@basic-files: - fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html * igt@gem_ctx_param@basic-default: - fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-apl-guc/igt@gem_ctx_pa...@basic-default.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/fi-apl-guc/igt@gem_ctx_pa...@basic-default.html * igt@i915_module_load@reload: - fi-skl-6260u: [PASS][5] -> [INCOMPLETE][6] ([k.org#204565]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-skl-6260u/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/fi-skl-6260u/igt@i915_module_l...@reload.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [PASS][7] -> [FAIL][8] ([fdo#109483]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html Warnings * igt@kms_chamelium@dp-crc-fast: - fi-cml-u2: [FAIL][9] ([fdo#110387]) -> [FAIL][10] ([fdo#110627]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483 [fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387 [fdo#110627]: https://bugs.freedesktop.org/show_bug.cgi?id=110627 [k.org#204565]: https://bugzilla.kernel.org/show_bug.cgi?id=204565 Participating hosts (53 -> 45) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6711 -> Patchwork_14025 CI-20190529: 20190529 CI_DRM_6711: 66992026e64fe4405ca25b1e978a98c7e132673b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14025: ae616484b0f1a2590bbbfd7637051ce687b78bd7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ae616484b0f1 drm/i915/icl: Add gen11 specific render breadcrumbs 302da876b5c3 drm/i915/icl: Add command cache invalidate 4241b319406b drm/i915/icl: Implement gen11 flush including tile cache == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14025/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Convert a few more bland dmesg info to be device specific
Looking around the GT initialisation, we have a few log messages we
think are interesting enough present to the user (such as the amount of L4
cache) and a few to inform them of the result of actions or conflicting
HW restrictions (i.e. quirks). These are device specific messages, so
use the dev family of printk.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 6 --
drivers/gpu/drm/i915/i915_drv.c| 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +++--
drivers/gpu/drm/i915/i915_gpu_error.c | 12 ++--
drivers/gpu/drm/i915/i915_pmu.c| 2 +-
5 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 696dea5ec7c6..e140da71aef3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -363,12 +363,14 @@ int i915_gem_init_stolen(struct drm_i915_private
*dev_priv)
mutex_init(&dev_priv->mm.stolen_lock);
if (intel_vgpu_active(dev_priv)) {
- DRM_INFO("iGVT-g active, disabling use of stolen memory\n");
+ dev_notice(dev_priv->drm.dev,
+ "iGVT-g active, disabling use of stolen memory\n");
return 0;
}
if (intel_vtd_active() && INTEL_GEN(dev_priv) < 8) {
- DRM_INFO("DMAR active, disabling use of stolen memory\n");
+ dev_notice(dev_priv->drm.dev,
+ "DMAR active, disabling use of stolen memory\n");
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7c62bc7950b..2541a3a1c229 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1102,7 +1102,8 @@ static void edram_detect(struct drm_i915_private
*dev_priv)
dev_priv->edram_size_mb =
gen9_edram_size_mb(dev_priv, edram_cap);
- DRM_INFO("Found %uMB of eDRAM\n", dev_priv->edram_size_mb);
+ dev_info(dev_priv->drm.dev,
+"Found %uMB of eDRAM\n", dev_priv->edram_size_mb);
}
/**
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e07c1ae971d7..fcf05c213b0a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3104,7 +3104,8 @@ static int i915_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.vma_ops.clear_pages = clear_pages;
if (unlikely(ggtt->do_idle_maps))
- DRM_INFO("applying Ironlake quirks for intel_iommu\n");
+ dev_notice(dev_priv->drm.dev,
+ "Applying Ironlake quirks for intel_iommu\n");
return 0;
}
@@ -3165,7 +3166,7 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
return ret;
if (intel_vtd_active())
- DRM_INFO("VT-d active for gfx access\n");
+ dev_info(i915->drm.dev, "VT-d active for gfx access\n");
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 6718fde1ed4c..0cdbbd32e29a 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1767,12 +1767,12 @@ void i915_capture_error_state(struct drm_i915_private
*i915,
if (!warned &&
ktime_get_real_seconds() - DRIVER_TIMESTAMP < DAY_AS_SECONDS(180)) {
- DRM_INFO("GPU hangs can indicate a bug anywhere in the entire
gfx stack, including userspace.\n");
- DRM_INFO("Please file a _new_ bug report on
bugs.freedesktop.org against DRI -> DRM/Intel\n");
- DRM_INFO("drm/i915 developers can then reassign to the right
component if it's not a kernel issue.\n");
- DRM_INFO("The gpu crash dump is required to analyze gpu hangs,
so please always attach it.\n");
- DRM_INFO("GPU crash dump saved to
/sys/class/drm/card%d/error\n",
-i915->drm.primary->index);
+ pr_info("GPU hangs can indicate a bug anywhere in the entire
gfx stack, including userspace.\n");
+ pr_info("Please file a _new_ bug report on bugs.freedesktop.org
against DRI -> DRM/Intel\n");
+ pr_info("drm/i915 developers can then reassign to the right
component if it's not a kernel issue.\n");
+ pr_info("The gpu crash dump is required to analyze gpu hangs,
so please always attach it.\n");
+ pr_info("GPU crash dump saved to /sys/class/drm/card%d/error\n",
+ i915->drm.primary->index);
warned = true;
}
}
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index c7ee0ab180e8..8e251e719390 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -1053,7 +1053,7 @@ void i9
Re: [Intel-gfx] [PATCH] dma-buf: Restore seqlock around dma_resv updates
Am 14.08.19 um 22:07 schrieb Daniel Vetter:
> On Wed, Aug 14, 2019 at 07:26:44PM +0100, Chris Wilson wrote:
>> Quoting Chris Wilson (2019-08-14 19:24:01)
>>> This reverts
>>> 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
>>> dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
>>> 0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence")
>>> 5d344f58da76 ("dma-buf: nuke reservation_object seq number")
> Oh I didn't realize they landed already.
>
>>> The scenario that defeats simply grabbing a set of shared/exclusive
>>> fences and using them blissfully under RCU is that any of those fences
>>> may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this
>>> scenario, while keeping the rcu_read_lock we need to establish that no
>>> fence was changed in the dma_resv after a read (or full) memory barrier.
> So if I'm reading correctly what Chris is saying here I guess my half
> comment in that other thread pointed at a real oversight. Since I still
> haven't checked and it's too late for real review not more for now.
Yeah, the root of the problem is that I didn't realized that fences
could be reused while in the RCU grace period.
Need to go a step back and try to come up with a complete new approach
for synchronization.
>>> Signed-off-by: Chris Wilson
>>> Cc: Chris Wilson
>> I said I needed to go lie down, that proves it.
> Yeah I guess we need to wait for Christian to wake up an have a working
> brain.
Well in that case you will need to wait for a few more years for my kids
to enter school age :)
Cheers,
Christian.
> -Daniel
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/icl: Add gen11 specific render breadcrumbs
Flush according to what gen11 expects when writing
breadcrumbs. As only the seqnowrite + flush differs
between engine and gens, enclose the footer to
helper.
v2: avoid problem of sane local naming by not using them
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 67 -
1 file changed, 47 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 9018afb4e9ef..a5d9b902d6e3 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2740,12 +2740,10 @@ static u32 *emit_preempt_busywait(struct i915_request
*request, u32 *cs)
return cs;
}
-static u32 *gen8_emit_fini_breadcrumb(struct i915_request *request, u32 *cs)
+static __always_inline u32*
+gen8_emit_fini_breadcrumb_footer(struct i915_request *request,
+u32 *cs)
{
- cs = gen8_emit_ggtt_write(cs,
- request->fence.seqno,
- request->timeline->hwsp_offset,
- 0);
*cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
@@ -2758,29 +2756,48 @@ static u32 *gen8_emit_fini_breadcrumb(struct
i915_request *request, u32 *cs)
return gen8_emit_wa_tail(request, cs);
}
+static u32 *gen8_emit_fini_breadcrumb(struct i915_request *request, u32 *cs)
+{
+ cs = gen8_emit_ggtt_write(cs,
+ request->fence.seqno,
+ request->timeline->hwsp_offset,
+ 0);
+
+ return gen8_emit_fini_breadcrumb_footer(request, cs);
+}
+
static u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *request, u32
*cs)
{
- /* XXX flush+write+CS_STALL all in one upsets gem_concurrent_blt:kbl */
cs = gen8_emit_ggtt_write_rcs(cs,
request->fence.seqno,
request->timeline->hwsp_offset,
PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
PIPE_CONTROL_DEPTH_CACHE_FLUSH |
PIPE_CONTROL_DC_FLUSH_ENABLE);
+
+ /* XXX flush+write+CS_STALL all in one upsets gem_concurrent_blt:kbl */
cs = gen8_emit_pipe_control(cs,
PIPE_CONTROL_FLUSH_ENABLE |
PIPE_CONTROL_CS_STALL,
0);
- *cs++ = MI_USER_INTERRUPT;
- *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
- if (intel_engine_has_semaphores(request->engine))
- cs = emit_preempt_busywait(request, cs);
+ return gen8_emit_fini_breadcrumb_footer(request, cs);
+}
- request->tail = intel_ring_offset(request, cs);
- assert_ring_tail_valid(request->ring, request->tail);
+static u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request *request,
+ u32 *cs)
+{
+ cs = gen8_emit_ggtt_write_rcs(cs,
+ request->fence.seqno,
+ request->timeline->hwsp_offset,
+ PIPE_CONTROL_CS_STALL |
+ PIPE_CONTROL_TILE_CACHE_FLUSH |
+ PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+ PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+ PIPE_CONTROL_DC_FLUSH_ENABLE |
+ PIPE_CONTROL_FLUSH_ENABLE);
- return gen8_emit_wa_tail(request, cs);
+ return gen8_emit_fini_breadcrumb_footer(request, cs);
}
static void execlists_park(struct intel_engine_cs *engine)
@@ -2876,6 +2893,21 @@ logical_ring_default_irqs(struct intel_engine_cs *engine)
engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift;
}
+static void rcs_submission_override(struct intel_engine_cs *engine)
+{
+ switch (INTEL_GEN(engine->i915)) {
+ case 12:
+ case 11:
+ engine->emit_flush = gen11_emit_flush_render;
+ engine->emit_fini_breadcrumb = gen11_emit_fini_breadcrumb_rcs;
+ break;
+ default:
+ engine->emit_flush = gen8_emit_flush_render;
+ engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb_rcs;
+ break;
+ }
+}
+
int intel_execlists_submission_setup(struct intel_engine_cs *engine)
{
tasklet_init(&engine->execlists.tasklet,
@@ -2885,13 +2917,8 @@ int intel_execlists_submission_setup(struct
intel_engine_cs *engine)
logical_ring_default_vfuncs(engine);
logical_ring_default_irqs(engine);
- if (engine->class == RENDER_CLASS) {
- if (INTEL_GEN(engine->i915) >= 11)
- engine->emit_flush = gen11_emit_flush
[Intel-gfx] ✗ Fi.CI.IGT: failure for ttm
== Series Details == Series: ttm URL : https://patchwork.freedesktop.org/series/65194/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6709_full -> Patchwork_14015_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14015_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14015_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_14015_full: ### IGT changes ### Possible regressions * igt@perf@enable-disable: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-skl1/igt@p...@enable-disable.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/shard-skl9/igt@p...@enable-disable.html Known issues Here are the changes found in Patchwork_14015_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@fifo-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +19 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb4/igt@gem_exec_sched...@fifo-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/shard-iclb6/igt@gem_exec_sched...@fifo-bsd1.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb8/igt@gem_exec_sched...@preemptive-hang-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/shard-iclb1/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_pwrite@huge-cpu-fbr: - shard-hsw: [PASS][7] -> [INCOMPLETE][8] ([fdo#103540]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-hsw8/igt@gem_pwr...@huge-cpu-fbr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/shard-hsw4/igt@gem_pwr...@huge-cpu-fbr.html * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#104108]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-skl2/igt@gem_soft...@noreloc-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/shard-skl7/igt@gem_soft...@noreloc-s3.html * igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: - shard-glk: [PASS][11] -> [FAIL][12] ([fdo#103060]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-glk6/igt@kms_f...@2x-modeset-vs-vblank-race-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/shard-glk5/igt@kms_f...@2x-modeset-vs-vblank-race-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#109507]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-skl4/igt@kms_f...@flip-vs-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/shard-skl3/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103166]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-x.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb2/igt@kms_psr@psr2_basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14015/shard-iclb3/igt@kms_psr@psr2_basic.html * igt@kms_psr@suspend: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([fdo#108972]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-skl6/igt@kms_...@suspend
Re: [Intel-gfx] [PATCH] drm/i915: Convert a few more bland dmesg info to be device specific
On Thu, 15 Aug 2019 11:36:04 +0200, Chris Wilson
wrote:
Looking around the GT initialisation, we have a few log messages we
think are interesting enough present to the user (such as the amount of
L4
cache) and a few to inform them of the result of actions or conflicting
HW restrictions (i.e. quirks). These are device specific messages, so
use the dev family of printk.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 6 --
drivers/gpu/drm/i915/i915_drv.c| 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +++--
drivers/gpu/drm/i915/i915_gpu_error.c | 12 ++--
drivers/gpu/drm/i915/i915_pmu.c| 2 +-
5 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 696dea5ec7c6..e140da71aef3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -363,12 +363,14 @@ int i915_gem_init_stolen(struct drm_i915_private
*dev_priv)
mutex_init(&dev_priv->mm.stolen_lock);
if (intel_vgpu_active(dev_priv)) {
- DRM_INFO("iGVT-g active, disabling use of stolen memory\n");
+ dev_notice(dev_priv->drm.dev,
+ "iGVT-g active, disabling use of stolen memory\n");
return 0;
}
if (intel_vtd_active() && INTEL_GEN(dev_priv) < 8) {
- DRM_INFO("DMAR active, disabling use of stolen memory\n");
+ dev_notice(dev_priv->drm.dev,
+ "DMAR active, disabling use of stolen memory\n");
nit: if we want to save few .rodata bytes, maybe:
"%s, disabling use of stolen memory\n", "iGVT-g active")
"%s, disabling use of stolen memory\n", "DMAR active")
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index a7c62bc7950b..2541a3a1c229 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1102,7 +1102,8 @@ static void edram_detect(struct drm_i915_private
*dev_priv)
dev_priv->edram_size_mb =
gen9_edram_size_mb(dev_priv, edram_cap);
- DRM_INFO("Found %uMB of eDRAM\n", dev_priv->edram_size_mb);
+ dev_info(dev_priv->drm.dev,
+"Found %uMB of eDRAM\n", dev_priv->edram_size_mb);
}
/**
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e07c1ae971d7..fcf05c213b0a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3104,7 +3104,8 @@ static int i915_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.vma_ops.clear_pages = clear_pages;
if (unlikely(ggtt->do_idle_maps))
- DRM_INFO("applying Ironlake quirks for intel_iommu\n");
+ dev_notice(dev_priv->drm.dev,
+ "Applying Ironlake quirks for intel_iommu\n");
return 0;
}
@@ -3165,7 +3166,7 @@ int i915_ggtt_probe_hw(struct drm_i915_private
*i915)
return ret;
if (intel_vtd_active())
- DRM_INFO("VT-d active for gfx access\n");
+ dev_info(i915->drm.dev, "VT-d active for gfx access\n");
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 6718fde1ed4c..0cdbbd32e29a 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1767,12 +1767,12 @@ void i915_capture_error_state(struct
drm_i915_private *i915,
if (!warned &&
ktime_get_real_seconds() - DRIVER_TIMESTAMP < DAY_AS_SECONDS(180))
{
- DRM_INFO("GPU hangs can indicate a bug anywhere in the entire gfx
stack, including userspace.\n");
- DRM_INFO("Please file a _new_ bug report on bugs.freedesktop.org
against DRI -> DRM/Intel\n");
- DRM_INFO("drm/i915 developers can then reassign to the right
component if it's not a kernel issue.\n");
- DRM_INFO("The gpu crash dump is required to analyze gpu hangs, so
please always attach it.\n");
- DRM_INFO("GPU crash dump saved to
/sys/class/drm/card%d/error\n",
-i915->drm.primary->index);
+ pr_info("GPU hangs can indicate a bug anywhere in the entire gfx
stack, including userspace.\n");
+ pr_info("Please file a _new_ bug report on bugs.freedesktop.org
against DRI -> DRM/Intel\n");
+ pr_info("drm/i915 developers can then reassign to the right component
if it's not a kernel issue.\n");
+ pr_info("The gpu crash dump is required to analyze gpu hangs, so
please always attach it.\n");
nit: s/gpu/GPU
+ pr_info("GPU crash dump saved to /sys/class/drm/card%d/error\n",
+ i915->drm.primary->index);
warned = true;
}
}
diff --git a/drivers/gpu/drm/i915/i915_pmu.c
b/driv
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Convert a few more bland dmesg info to be device specific
== Series Details == Series: drm/i915: Convert a few more bland dmesg info to be device specific URL : https://patchwork.freedesktop.org/series/65253/ State : success == Summary == CI Bug Log - changes from CI_DRM_6711 -> Patchwork_14027 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/ Known issues Here are the changes found in Patchwork_14027 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_execlists: - fi-skl-gvtdvm: [PASS][1] -> [DMESG-FAIL][2] ([fdo#08]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html * igt@i915_selftest@live_requests: - fi-byt-j1900: [PASS][3] -> [INCOMPLETE][4] ([fdo#102657]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-byt-j1900/igt@i915_selftest@live_requests.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/fi-byt-j1900/igt@i915_selftest@live_requests.html Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-cml-u2: [FAIL][5] ([fdo#110387]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657 [fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387 [fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08 Participating hosts (53 -> 46) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6711 -> Patchwork_14027 CI-20190529: 20190529 CI_DRM_6711: 66992026e64fe4405ca25b1e978a98c7e132673b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14027: 8239e19e9476345d9207f7a9a69441fabb930c74 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8239e19e9476 drm/i915: Convert a few more bland dmesg info to be device specific == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14027/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftest/buddy: fixup igt_buddy_alloc_range
Dan reported the following static checker warning:
drivers/gpu/drm/i915/selftests/i915_buddy.c:670 igt_buddy_alloc_range()
error: we previously assumed 'block' could be null (see line 665)
Reported-by: Dan Carpenter
Signed-off-by: Matthew Auld
Cc: Dan Carpenter
Cc: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_buddy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_buddy.c
b/drivers/gpu/drm/i915/selftests/i915_buddy.c
index b839dd99dd1f..23f784eae1e7 100644
--- a/drivers/gpu/drm/i915/selftests/i915_buddy.c
+++ b/drivers/gpu/drm/i915/selftests/i915_buddy.c
@@ -665,6 +665,7 @@ static int igt_buddy_alloc_range(void *arg)
if (!block) {
pr_err("alloc_range has no blocks\n");
err = -EINVAL;
+ break;
}
if (i915_buddy_block_offset(block) != offset) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 hmm 08/11] drm/radeon: use mmu_notifier_get/put for struct radeon_mn
Am 07.08.19 um 01:15 schrieb Jason Gunthorpe:
From: Jason Gunthorpe
radeon is using a device global hash table to track what mmu_notifiers
have been registered on struct mm. This is better served with the new
get/put scheme instead.
radeon has a bug where it was not blocking notifier release() until all
the BO's had been invalidated. This could result in a use after free of
pages the BOs. This is tied into a second bug where radeon left the
notifiers running endlessly even once the interval tree became
empty. This could result in a use after free with module unload.
Both are fixed by changing the lifetime model, the BOs exist in the
interval tree with their natural lifetimes independent of the mm_struct
lifetime using the get/put scheme. The release runs synchronously and just
does invalidate_start across the entire interval tree to create the
required DMA fence.
Additions to the interval tree after release are already impossible as
only current->mm is used during the add.
Signed-off-by: Jason Gunthorpe
Acked-by: Christian König
But I'm wondering if we shouldn't completely drop radeon userptr support.
It's just to buggy,
Christian.
---
drivers/gpu/drm/radeon/radeon.h| 3 -
drivers/gpu/drm/radeon/radeon_device.c | 2 -
drivers/gpu/drm/radeon/radeon_drv.c| 2 +
drivers/gpu/drm/radeon/radeon_mn.c | 157 ++---
4 files changed, 38 insertions(+), 126 deletions(-)
AMD team: I wonder if kfd has similar lifetime issues?
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 32808e50be12f8..918164f90b114a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2451,9 +2451,6 @@ struct radeon_device {
/* tracking pinned memory */
u64 vram_pin_size;
u64 gart_pin_size;
-
- struct mutexmn_lock;
- DECLARE_HASHTABLE(mn_hash, 7);
};
bool radeon_is_px(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index dceb554e567446..788b1d8a80e660 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1325,8 +1325,6 @@ int radeon_device_init(struct radeon_device *rdev,
init_rwsem(&rdev->pm.mclk_lock);
init_rwsem(&rdev->exclusive_lock);
init_waitqueue_head(&rdev->irq.vblank_queue);
- mutex_init(&rdev->mn_lock);
- hash_init(rdev->mn_hash);
r = radeon_gem_init(rdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index a6cbe11f79c611..b6535ac91fdb74 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -624,6 +625,7 @@ static void __exit radeon_exit(void)
{
pci_unregister_driver(pdriver);
radeon_unregister_atpx_handler();
+ mmu_notifier_synchronize();
}
module_init(radeon_init);
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c
b/drivers/gpu/drm/radeon/radeon_mn.c
index 8c3871ed23a9f0..fc8254273a800b 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -37,17 +37,8 @@
#include "radeon.h"
struct radeon_mn {
- /* constant after initialisation */
- struct radeon_device*rdev;
- struct mm_struct*mm;
struct mmu_notifier mn;
- /* only used on destruction */
- struct work_struct work;
-
- /* protected by rdev->mn_lock */
- struct hlist_node node;
-
/* objects protected by lock */
struct mutexlock;
struct rb_root_cached objects;
@@ -58,55 +49,6 @@ struct radeon_mn_node {
struct list_headbos;
};
-/**
- * radeon_mn_destroy - destroy the rmn
- *
- * @work: previously sheduled work item
- *
- * Lazy destroys the notifier from a work item
- */
-static void radeon_mn_destroy(struct work_struct *work)
-{
- struct radeon_mn *rmn = container_of(work, struct radeon_mn, work);
- struct radeon_device *rdev = rmn->rdev;
- struct radeon_mn_node *node, *next_node;
- struct radeon_bo *bo, *next_bo;
-
- mutex_lock(&rdev->mn_lock);
- mutex_lock(&rmn->lock);
- hash_del(&rmn->node);
- rbtree_postorder_for_each_entry_safe(node, next_node,
-&rmn->objects.rb_root, it.rb) {
-
- interval_tree_remove(&node->it, &rmn->objects);
- list_for_each_entry_safe(bo, next_bo, &node->bos, mn_list) {
- bo->mn = NULL;
- list_del_init(&bo->mn_list);
- }
- kfree(node);
- }
- mutex_unlock(&rmn->lock);
- mutex_unlock(&rdev->mn_lock);
- mmu_notifier_unregister(&rmn->mn, rmn->mm);
- kfree(rmn);
-}
-
-/**
- * radeon_mn
Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic eviction
On Tue, 30 Jul 2019 at 17:26, Daniel Vetter wrote: > > On Thu, Jun 27, 2019 at 09:55:59PM +0100, Matthew Auld wrote: > > Support basic eviction for regions. > > > > Signed-off-by: Matthew Auld > > Cc: Joonas Lahtinen > > Cc: Abdiel Janulgue > > So from a very high level this looks like it was largely modelled after > i915_gem_shrink.c and not i915_gem_evict.c (our other "make room, we're > running out of stuff" code). Any specific reasons? IIRC I think it was originally based on the patches that exposed stolen-memory to userspace from a few years ago. > > I think i915_gem_evict is a lot closer match for what we want for vram (it > started out to manage severely limitted GTT on gen2/3/4) after all. With > the complication that we'll have to manage physical memory with multiple > virtual mappings of it on top, so unfortunately we can't just reuse the > locking patter Chris has come up with in his struct_mutex-removal branch. > But at least conceptually it should be a lot closer. When you say make it more like i915_gem_evict, what does that mean? Are you talking about the eviction roster stuff, or the placement/locking of the eviction logic, with it being deep down in get_pages? > > But I might be entirely off the track with reconstructing how this code > came to be, so please elaborate a bit. > > Thanks, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for dma-buf: Restore seqlock around dma_resv updates
== Series Details == Series: dma-buf: Restore seqlock around dma_resv updates URL : https://patchwork.freedesktop.org/series/65196/ State : success == Summary == CI Bug Log - changes from CI_DRM_6709_full -> Patchwork_14016_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14016_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-apl: [PASS][1] -> [FAIL][2] ([fdo#109661]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-apl6/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-apl1/igt@gem_...@reset-stress.html * igt@gem_exec_schedule@preempt-contexts-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +19 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb2/igt@gem_exec_sched...@preempt-contexts-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-iclb5/igt@gem_exec_sched...@preempt-contexts-bsd2.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +6 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb8/igt@gem_exec_sched...@preemptive-hang-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-iclb1/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +5 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-apl5/igt@gem_workarou...@suspend-resume-context.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-apl2/igt@gem_workarou...@suspend-resume-context.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][9] -> [FAIL][10] ([fdo#105363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-glk6/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-glk1/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#105363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-skl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-skl8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +6 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-skl1/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103166]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-x.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-iclb5/igt@kms_psr@psr2_sprite_plane_move.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-apl4/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-apl6/igt@kms_setm...@basic.html * igt@perf@enable-disable: - shard-iclb: [PASS][23] -> [INCOMPLETE][24] ([fdo#107713]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb4/igt@p...@enable-disable.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14016/shard-iclb7/igt@p...@enable-disable.html Possible fixes * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [DMESG-WARN][25
Re: [Intel-gfx] [PATCH] drm/i915/selftest/buddy: fixup igt_buddy_alloc_range
Quoting Matthew Auld (2019-08-15 11:32:10) > Dan reported the following static checker warning: > > drivers/gpu/drm/i915/selftests/i915_buddy.c:670 igt_buddy_alloc_range() > error: we previously assumed 'block' could be null (see line 665) > > Reported-by: Dan Carpenter > Signed-off-by: Matthew Auld > Cc: Dan Carpenter > Cc: Chris Wilson Reviewed-by: Dan Carpenter -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move tasklet kicking to __i915_request_queue caller
Chris Wilson writes: > Since __i915_request_queue() may be called from hardirq (timer) context, > we cannot use local_bh_disable/enable at the lower level. As we do want > to kick the tasklet to speed up initial submission or preemption for > normal client submission, lift it to the normal process context > callpath. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/i915_request.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index 4021334dd2c5..8a2bc1d317e4 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -1203,12 +1203,10 @@ void __i915_request_queue(struct i915_request *rq, >* decide whether to preempt the entire chain so that it is ready to >* run at the earliest possible convenience. >*/ > - local_bh_disable(); > i915_sw_fence_commit(&rq->semaphore); > if (attr && rq->engine->schedule) > rq->engine->schedule(rq, attr); > i915_sw_fence_commit(&rq->submit); > - local_bh_enable(); /* Kick the execlists tasklet if just scheduled */ Was this here to only optimize the latency from schedule to resubmission? Or is it actually guarding something? -Mika > } > > void i915_request_add(struct i915_request *rq) > @@ -1247,7 +1245,9 @@ void i915_request_add(struct i915_request *rq) > if (list_empty(&rq->sched.signalers_list)) > attr.priority |= I915_PRIORITY_WAIT; > > + local_bh_disable(); > __i915_request_queue(rq, &attr); > + local_bh_enable(); /* Kick the execlists tasklet if just scheduled */ > > /* >* In typical scenarios, we do not expect the previous request on > -- > 2.23.0.rc1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-intel-fixes
On Thu, Aug 15, 2019 at 9:42 AM Jani Nikula wrote: > > > Hi Dave & Daniel - > > One use after free fix for GVT. > > It doesn't have a Link: tag because dim doesn't check that while > applying the pull, and, for some reason, it was also not checked when I > pushed out the branch. Possibly because it's in a merge? Anyway, I only > got the complaint when making the pull request, which is too late. Hm, sounds like the flag settings for the checker are wrong, for "foreign" trees dim doesn't insist on the Link: tag. So maybe need to flip that around to match what we do on the receiving end of a pull? -Daniel > > drm-intel-fixes-2019-08-15: > drm/i915 fixes for v5.4-rc5: > - GVT use-after-free fix > > BR, > Jani. > > The following changes since commit d45331b00ddb179e291766617259261c112db872: > > Linux 5.3-rc4 (2019-08-11 13:26:41 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-08-15 > > for you to fetch changes up to daa37200d48906d71c63ce178bf7d410b7e07082: > > Merge tag 'gvt-fixes-2019-08-13' of https://github.com/intel/gvt-linux into > drm-intel-fixes (2019-08-13 16:26:34 +0300) > > > drm/i915 fixes for v5.4-rc5: > - GVT use-after-free fix > > > Dan Carpenter (1): > drm/i915: Use after free in error path in intel_vgpu_create_workload() > > Jani Nikula (1): > Merge tag 'gvt-fixes-2019-08-13' of https://github.com/intel/gvt-linux > into drm-intel-fixes > > drivers/gpu/drm/i915/gvt/scheduler.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > -- > Jani Nikula, Intel Open Source Graphics Center -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache (rev2)
== Series Details == Series: series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache (rev2) URL : https://patchwork.freedesktop.org/series/65226/ State : warning == Summary == $ dim checkpatch origin/drm-tip 258ad12f28aa drm/i915/icl: Implement gen11 flush including tile cache -:30: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #30: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:211: +#define PIPE_CONTROL_TILE_CACHE_FLUSH(1<<28) /* gen11+ */ ^ total: 0 errors, 0 warnings, 1 checks, 80 lines checked a2dddefbe7ad drm/i915/icl: Add command cache invalidate -:20: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #20: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:211: +#define PIPE_CONTROL_COMMAND_CACHE_INVALIDATE(1<<29) /* gen11+ */ ^ total: 0 errors, 0 warnings, 1 checks, 14 lines checked fcda2861f8c9 drm/i915/icl: Add gen11 specific render breadcrumbs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move tasklet kicking to __i915_request_queue caller
Quoting Mika Kuoppala (2019-08-15 12:35:37) > Chris Wilson writes: > > > Since __i915_request_queue() may be called from hardirq (timer) context, > > we cannot use local_bh_disable/enable at the lower level. As we do want > > to kick the tasklet to speed up initial submission or preemption for > > normal client submission, lift it to the normal process context > > callpath. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/i915_request.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_request.c > > b/drivers/gpu/drm/i915/i915_request.c > > index 4021334dd2c5..8a2bc1d317e4 100644 > > --- a/drivers/gpu/drm/i915/i915_request.c > > +++ b/drivers/gpu/drm/i915/i915_request.c > > @@ -1203,12 +1203,10 @@ void __i915_request_queue(struct i915_request *rq, > >* decide whether to preempt the entire chain so that it is ready to > >* run at the earliest possible convenience. > >*/ > > - local_bh_disable(); > > i915_sw_fence_commit(&rq->semaphore); > > if (attr && rq->engine->schedule) > > rq->engine->schedule(rq, attr); > > i915_sw_fence_commit(&rq->submit); > > - local_bh_enable(); /* Kick the execlists tasklet if just scheduled */ > > Was this here to only optimize the latency from schedule > to resubmission? It's only for latency minimisation. If we don't do it now, the raise_softirq will not be until the process hits the scheduler. Fence -> backend is all irq-spinlocks. -Chris ___ 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: Comment userptr recursion on struct_mutex (rev3)
== Series Details == Series: series starting with [1/2] drm/i915: Comment userptr recursion on struct_mutex (rev3) URL : https://patchwork.freedesktop.org/series/65177/ State : success == Summary == CI Bug Log - changes from CI_DRM_6709_full -> Patchwork_14017_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14017_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@flink: - shard-apl: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-apl6/igt@drm_import_exp...@flink.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-apl2/igt@drm_import_exp...@flink.html * igt@gem_exec_schedule@preempt-contexts-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +15 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb2/igt@gem_exec_sched...@preempt-contexts-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-iclb3/igt@gem_exec_sched...@preempt-contexts-bsd2.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_pwrite@huge-cpu-fbr: - shard-hsw: [PASS][7] -> [INCOMPLETE][8] ([fdo#103540]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-hsw8/igt@gem_pwr...@huge-cpu-fbr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-hsw8/igt@gem_pwr...@huge-cpu-fbr.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-apl8/igt@gem_soft...@noreloc-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-apl4/igt@gem_soft...@noreloc-s3.html * igt@gem_sync@basic-many-each: - shard-kbl: [PASS][11] -> [INCOMPLETE][12] ([fdo#103665]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-kbl3/igt@gem_s...@basic-many-each.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-kbl1/igt@gem_s...@basic-many-each.html * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb4/igt@kms_b...@extended-modeset-hang-newfb-with-reset-render-a.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-iclb7/igt@kms_b...@extended-modeset-hang-newfb-with-reset-render-a.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#110741]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_legacy@cursor-vs-flip-atomic: - shard-hsw: [PASS][17] -> [FAIL][18] ([fdo#103355]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-hsw5/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +6 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_psr@psr2_cursor_plane_move: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6709/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14017/shard-iclb3/igt@kms_psr@psr2_cursor_plane_move.html * igt@kms_setmode@basic: - shard-apl:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache (rev2)
== Series Details == Series: series starting with [1/3] drm/i915/icl: Implement gen11 flush including tile cache (rev2) URL : https://patchwork.freedesktop.org/series/65226/ State : success == Summary == CI Bug Log - changes from CI_DRM_6711 -> Patchwork_14028 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/ Known issues Here are the changes found in Patchwork_14028 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-cml-u2: [FAIL][3] ([fdo#110387]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387 Participating hosts (53 -> 46) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6711 -> Patchwork_14028 CI-20190529: 20190529 CI_DRM_6711: 66992026e64fe4405ca25b1e978a98c7e132673b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14028: fcda2861f8c9c89c1e1786716b598db1c9ef9fd6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == fcda2861f8c9 drm/i915/icl: Add gen11 specific render breadcrumbs a2dddefbe7ad drm/i915/icl: Add command cache invalidate 258ad12f28aa drm/i915/icl: Implement gen11 flush including tile cache == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14028/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move tasklet kicking to __i915_request_queue caller
Chris Wilson writes: > Quoting Mika Kuoppala (2019-08-15 12:35:37) >> Chris Wilson writes: >> >> > Since __i915_request_queue() may be called from hardirq (timer) context, >> > we cannot use local_bh_disable/enable at the lower level. As we do want >> > to kick the tasklet to speed up initial submission or preemption for >> > normal client submission, lift it to the normal process context >> > callpath. >> > >> > Signed-off-by: Chris Wilson >> > --- >> > drivers/gpu/drm/i915/i915_request.c | 4 ++-- >> > 1 file changed, 2 insertions(+), 2 deletions(-) >> > >> > diff --git a/drivers/gpu/drm/i915/i915_request.c >> > b/drivers/gpu/drm/i915/i915_request.c >> > index 4021334dd2c5..8a2bc1d317e4 100644 >> > --- a/drivers/gpu/drm/i915/i915_request.c >> > +++ b/drivers/gpu/drm/i915/i915_request.c >> > @@ -1203,12 +1203,10 @@ void __i915_request_queue(struct i915_request *rq, >> >* decide whether to preempt the entire chain so that it is ready to >> >* run at the earliest possible convenience. >> >*/ >> > - local_bh_disable(); >> > i915_sw_fence_commit(&rq->semaphore); >> > if (attr && rq->engine->schedule) >> > rq->engine->schedule(rq, attr); >> > i915_sw_fence_commit(&rq->submit); >> > - local_bh_enable(); /* Kick the execlists tasklet if just scheduled */ >> >> Was this here to only optimize the latency from schedule >> to resubmission? > > It's only for latency minimisation. If we don't do it now, the > raise_softirq will not be until the process hits the scheduler. > > Fence -> backend is all irq-spinlocks. Reviewed-by: Mika Kuoppala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftest/buddy: fixup igt_buddy_alloc_range
== Series Details ==
Series: drm/i915/selftest/buddy: fixup igt_buddy_alloc_range
URL : https://patchwork.freedesktop.org/series/65256/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6711 -> Patchwork_14029
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/
Known issues
Here are the changes found in Patchwork_14029 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_exec_suspend@basic-s3:
- fi-skl-6700k2: [PASS][3] -> [INCOMPLETE][4] ([fdo#104108])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-skl-6700k2/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/fi-skl-6700k2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_render_tiled_blits@basic:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/fi-icl-u3/igt@gem_render_tiled_bl...@basic.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6600u: [PASS][7] -> [INCOMPLETE][8] ([fdo#107807])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-skl-6600u/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/fi-skl-6600u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [PASS][9] -> [DMESG-FAIL][10] ([fdo#08])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
Possible fixes
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [FAIL][11] ([fdo#110387]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [FAIL][13] ([fdo#103167]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [SKIP][15] ([fdo#109271]) -> [FAIL][16] ([fdo#110829])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6711/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
[fdo#110829]: https://bugs.freedesktop.org/show_bug.cgi?id=110829
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
Participating hosts (53 -> 46)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6711 -> Patchwork_14029
CI-20190529: 20190529
CI_DRM_6711: 66992026e64fe4405ca25b1e978a98c7e132673b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5134: 81df2f22385bc275975cf199d962eed9bc10f916 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14029: eb1f2b756e1574bc039c9e206250da3a01c1ddb5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
eb1f2b756e15 drm/i915/selftest/buddy: fixup igt_buddy_alloc_range
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14029/
___
Intel-gfx mailing
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu, Aug 15, 2019 at 3:04 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 10:44:29AM +0200, Michal Hocko wrote: > > > As the oom reaper is the primary guarantee of the oom handling forward > > progress it cannot be blocked on anything that might depend on blockable > > memory allocations. These are not really easy to track because they > > might be indirect - e.g. notifier blocks on a lock which other context > > holds while allocating memory or waiting for a flusher that needs memory > > to perform its work. > > But lockdep *does* track all this and fs_reclaim_acquire() was created > to solve exactly this problem. > > fs_reclaim is a lock and it flows through all the usual lockdep > schemes like any other lock. Any time the page allocator wants to do > something the would deadlock with reclaim it takes the lock. > > Failure is expressed by a deadlock cycle in the lockdep map, and > lockdep can handle arbitary complexity through layers of locks, work > queues, threads, etc. > > What is missing? Lockdep doens't seen everything by far. E.g. a wait_event will be caught by the annotations here, but not by lockdep. Plus lockdep does not see through the wait_event, and doesn't realize if e.g. that event will never signal because the worker is part of the deadlock loop. cross-release was supposed to fix that, but seems like that will never land. And since we're talking about mmu notifiers here and gpus/dma engines. We have dma_fence_wait, which can wait for any hw/driver in the system that takes part in shared/zero-copy buffer processing. Which at least on the graphics side is everything. This pulls in enormous amounts of deadlock potential that lockdep simply is blind about and will never see. Arming might_sleep catches them all. Cheers, Daniel PS: Don't ask me about why we need these semantics for oom_reaper, like I said just trying to follow the rules. -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu 15-08-19 09:23:44, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 08:58:29AM +0200, Daniel Vetter wrote:
> > On Wed, Aug 14, 2019 at 08:58:05PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Aug 14, 2019 at 10:20:24PM +0200, Daniel Vetter wrote:
> > > > In some special cases we must not block, but there's not a
> > > > spinlock, preempt-off, irqs-off or similar critical section already
> > > > that arms the might_sleep() debug checks. Add a non_block_start/end()
> > > > pair to annotate these.
> > > >
> > > > This will be used in the oom paths of mmu-notifiers, where blocking is
> > > > not allowed to make sure there's forward progress. Quoting Michal:
> > > >
> > > > "The notifier is called from quite a restricted context - oom_reaper -
> > > > which shouldn't depend on any locks or sleepable conditionals. The code
> > > > should be swift as well but we mostly do care about it to make a forward
> > > > progress. Checking for sleepable context is the best thing we could come
> > > > up with that would describe these demands at least partially."
> > >
> > > But this describes fs_reclaim_acquire() - is there some reason we are
> > > conflating fs_reclaim with non-sleeping?
> >
> > No idea why you tie this into fs_reclaim. We can definitly sleep in there,
> > and for e.g. kswapd (which also wraps everything in fs_reclaim) we're
> > event supposed to I thought. To make sure we can get at the last bit of
> > memory by flushing all the queues and waiting for everything to be cleaned
> > out.
>
> AFAIK the point of fs_reclaim is to prevent "indirect dependency upon
> the page allocator" ie a justification that was given this !blockable
> stuff.
>
> For instance:
>
> fs_reclaim_acquire()
> kmalloc(GFP_KERNEL) <- lock dep assertion
>
> And further, Michal's concern about indirectness through locks is also
> handled by lockdep:
>
>CPU0 CPU1
> mutex_lock()
> kmalloc(GFP_KERNEL)
> mutex_unlock()
> fs_reclaim_acquire()
> mutex_lock() <- lock dep assertion
>
> In other words, to prevent recursion into the page allocator you use
> fs_reclaim_acquire(), and lockdep verfies it in its usual robust way.
fs_reclaim_acquire is about FS/IO recursions IIUC. We are talking about
any !GFP_NOWAIT allocation context here and any {in}direct dependency on
it. Whether fs_reclaim_acquire can be reused for that I do not know
because I am not familiar with the lockdep machinery enough
> I asked Tejun about this once in regards to WQ_MEM_RECLAIM and he
> explained that it means you can't call the allocator functions in a
> way that would recurse into reclaim (ie instead use instead GFP_ATOMIC, or
> tolerate allocation failure, or various other things).
>
> So, the reason I bring it up is half the justifications you posted for
> blockable had to do with not recursing into reclaim and deadlocking,
> and didn't seem to have much to do with blocking.
>
> I'm asking if *non-blocking* is really the requirement or if this is
> just the usual 'do not deadlock on the allocator' thing reclaim paths
> alread have?
No, non-blocking is a very coarse approximation of what we really need.
But it should give us even a stronger condition. Essentially any sleep
other than a preemption shouldn't be allowed in that context.
--
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Convert a few more bland dmesg info to be device specific
On Thu, 15 Aug 2019, Chris Wilson wrote:
> Looking around the GT initialisation, we have a few log messages we
> think are interesting enough present to the user (such as the amount of L4
> cache) and a few to inform them of the result of actions or conflicting
> HW restrictions (i.e. quirks). These are device specific messages, so
> use the dev family of printk.
So drm_print.h has DRM_DEV_* variants of all the debug log macros. I am
not particularly fond of them, and I'd prefer we added sensible, short
functions that take struct drm_device instead of struct device, and
converted all of i915 to them.
However, I'm even less fond of having a mixture of everything in
drm_print.h *and* device.h *and* printk.h.
Thoughts?
BR,
Jani.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Michal Wajdeczko
> ---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 6 --
> drivers/gpu/drm/i915/i915_drv.c| 3 ++-
> drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +++--
> drivers/gpu/drm/i915/i915_gpu_error.c | 12 ++--
> drivers/gpu/drm/i915/i915_pmu.c| 2 +-
> 5 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index 696dea5ec7c6..e140da71aef3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -363,12 +363,14 @@ int i915_gem_init_stolen(struct drm_i915_private
> *dev_priv)
> mutex_init(&dev_priv->mm.stolen_lock);
>
> if (intel_vgpu_active(dev_priv)) {
> - DRM_INFO("iGVT-g active, disabling use of stolen memory\n");
> + dev_notice(dev_priv->drm.dev,
> +"iGVT-g active, disabling use of stolen memory\n");
> return 0;
> }
>
> if (intel_vtd_active() && INTEL_GEN(dev_priv) < 8) {
> - DRM_INFO("DMAR active, disabling use of stolen memory\n");
> + dev_notice(dev_priv->drm.dev,
> +"DMAR active, disabling use of stolen memory\n");
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index a7c62bc7950b..2541a3a1c229 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1102,7 +1102,8 @@ static void edram_detect(struct drm_i915_private
> *dev_priv)
> dev_priv->edram_size_mb =
> gen9_edram_size_mb(dev_priv, edram_cap);
>
> - DRM_INFO("Found %uMB of eDRAM\n", dev_priv->edram_size_mb);
> + dev_info(dev_priv->drm.dev,
> + "Found %uMB of eDRAM\n", dev_priv->edram_size_mb);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index e07c1ae971d7..fcf05c213b0a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3104,7 +3104,8 @@ static int i915_gmch_probe(struct i915_ggtt *ggtt)
> ggtt->vm.vma_ops.clear_pages = clear_pages;
>
> if (unlikely(ggtt->do_idle_maps))
> - DRM_INFO("applying Ironlake quirks for intel_iommu\n");
> + dev_notice(dev_priv->drm.dev,
> +"Applying Ironlake quirks for intel_iommu\n");
>
> return 0;
> }
> @@ -3165,7 +3166,7 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
> return ret;
>
> if (intel_vtd_active())
> - DRM_INFO("VT-d active for gfx access\n");
> + dev_info(i915->drm.dev, "VT-d active for gfx access\n");
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 6718fde1ed4c..0cdbbd32e29a 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1767,12 +1767,12 @@ void i915_capture_error_state(struct drm_i915_private
> *i915,
>
> if (!warned &&
> ktime_get_real_seconds() - DRIVER_TIMESTAMP < DAY_AS_SECONDS(180)) {
> - DRM_INFO("GPU hangs can indicate a bug anywhere in the entire
> gfx stack, including userspace.\n");
> - DRM_INFO("Please file a _new_ bug report on
> bugs.freedesktop.org against DRI -> DRM/Intel\n");
> - DRM_INFO("drm/i915 developers can then reassign to the right
> component if it's not a kernel issue.\n");
> - DRM_INFO("The gpu crash dump is required to analyze gpu hangs,
> so please always attach it.\n");
> - DRM_INFO("GPU crash dump saved to
> /sys/class/drm/card%d/error\n",
> - i915->drm.primary->index);
> + pr_info("GPU hangs can indicate a bug anywhere in the entire
> gfx stack, including userspace.\n");
> + pr_info("Please file a _new_ bug report on bugs.freedesktop.org
> against DRI -> DRM/Intel\n");
> + pr_info("drm/i915 developers can then reassign to the right
> compone
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu 15-08-19 10:04:15, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 10:44:29AM +0200, Michal Hocko wrote: > > > As the oom reaper is the primary guarantee of the oom handling forward > > progress it cannot be blocked on anything that might depend on blockable > > memory allocations. These are not really easy to track because they > > might be indirect - e.g. notifier blocks on a lock which other context > > holds while allocating memory or waiting for a flusher that needs memory > > to perform its work. > > But lockdep *does* track all this and fs_reclaim_acquire() was created > to solve exactly this problem. > > fs_reclaim is a lock and it flows through all the usual lockdep > schemes like any other lock. Any time the page allocator wants to do > something the would deadlock with reclaim it takes the lock. Our emails have crossed. Even if fs_reclaim can be re-purposed for other than FS/IO reclaim contexts which I am not sure about I think that lockdep is too heavy weight for the purpose of this debugging aid in the first place. The non block mode is really something as simple as "hey mmu notifier you are only allowed to do a lightweight processing, if you cannot guarantee that then just back off". The annotation will give us a warning if the notifier gets out of this promise. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gtt: Fold gen8 insertions into one
As we give page directory pointer (lvl 3) structure
for pte insertion, we can fold both versions into
one function by teaching it to get pdp regardless
of top level.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 84 -
1 file changed, 48 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e07c1ae971d7..85fd7ea0dd76 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -910,6 +910,32 @@ static inline unsigned int gen8_pd_top_count(const struct
i915_address_space *vm
return (vm->total + (1ull << shift) - 1) >> shift;
}
+static inline struct i915_page_directory *
+gen8_pdp_for_page_index(struct i915_address_space * const vm, const u64 idx)
+{
+ struct i915_ppgtt * const ppgtt = i915_vm_to_ppgtt(vm);
+ struct i915_page_directory *pd = ppgtt->pd;
+
+ switch (vm->top) {
+ case 3:
+ pd = i915_pd_entry(pd, gen8_pd_index(idx, 3));
+ /* fall through */
+ case 2:
+ break;
+
+ default:
+ GEM_BUG_ON(vm->top);
+ }
+
+ return pd;
+}
+
+static inline struct i915_page_directory *
+gen8_pdp_for_page_address(struct i915_address_space * const vm, const u64 addr)
+{
+ return gen8_pdp_for_page_index(vm, addr >> GEN8_PTE_SHIFT);
+}
+
static void __gen8_ppgtt_cleanup(struct i915_address_space *vm,
struct i915_page_directory *pd,
int count, int lvl)
@@ -1182,23 +1208,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_ppgtt *ppgtt,
return idx;
}
-static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm,
- struct i915_vma *vma,
- enum i915_cache_level cache_level,
- u32 flags)
-{
- struct i915_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
- struct sgt_dma iter = sgt_dma(vma);
-
- gen8_ppgtt_insert_pte_entries(ppgtt, ppgtt->pd, &iter,
- vma->node.start >> GEN8_PTE_SHIFT,
- cache_level, flags);
-
- vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
-}
-
static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
- struct i915_page_directory *pml4,
struct sgt_dma *iter,
enum i915_cache_level cache_level,
u32 flags)
@@ -1208,9 +1218,9 @@ static void gen8_ppgtt_insert_huge_entries(struct
i915_vma *vma,
dma_addr_t rem = iter->sg->length;
do {
- struct i915_page_directory *pdp =
- i915_pd_entry(pml4, __gen8_pte_index(start, 3));
- struct i915_page_directory *pd =
+ struct i915_page_directory * const pdp =
+ gen8_pdp_for_page_address(vma->vm, start);
+ struct i915_page_directory * const pd =
i915_pd_entry(pdp, __gen8_pte_index(start, 2));
gen8_pte_t encode = pte_encode;
unsigned int maybe_64K = -1;
@@ -1316,26 +1326,31 @@ static void gen8_ppgtt_insert_huge_entries(struct
i915_vma *vma,
} while (iter->sg);
}
-static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
- struct i915_vma *vma,
- enum i915_cache_level cache_level,
- u32 flags)
+static void gen8_ppgtt_insert(struct i915_address_space *vm,
+ struct i915_vma *vma,
+ enum i915_cache_level cache_level,
+ u32 flags)
{
- struct i915_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
+ struct i915_ppgtt * const ppgtt = i915_vm_to_ppgtt(vm);
struct sgt_dma iter = sgt_dma(vma);
- struct i915_page_directory * const pml4 = ppgtt->pd;
if (vma->page_sizes.sg > I915_GTT_PAGE_SIZE) {
- gen8_ppgtt_insert_huge_entries(vma, pml4, &iter, cache_level,
+ gen8_ppgtt_insert_huge_entries(vma, &iter, cache_level,
flags);
} else {
u64 idx = vma->node.start >> GEN8_PTE_SHIFT;
- while ((idx = gen8_ppgtt_insert_pte_entries(ppgtt,
- i915_pd_entry(pml4,
gen8_pd_index(idx, 3)),
- &iter, idx,
cache_level,
- flags)))
- ;
+ do {
+ struct i915_page_directory * const pdp =
+ gen8_pdp_for_page_index(vm, idx);
+
+
Re: [Intel-gfx] [PATCH] drm/i915/gtt: Fold gen8 insertions into one
Quoting Mika Kuoppala (2019-08-15 14:50:00)
> As we give page directory pointer (lvl 3) structure
> for pte insertion, we can fold both versions into
> one function by teaching it to get pdp regardless
> of top level.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 84 -
> 1 file changed, 48 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index e07c1ae971d7..85fd7ea0dd76 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -910,6 +910,32 @@ static inline unsigned int gen8_pd_top_count(const
> struct i915_address_space *vm
> return (vm->total + (1ull << shift) - 1) >> shift;
> }
>
> +static inline struct i915_page_directory *
> +gen8_pdp_for_page_index(struct i915_address_space * const vm, const u64 idx)
> +{
> + struct i915_ppgtt * const ppgtt = i915_vm_to_ppgtt(vm);
> + struct i915_page_directory *pd = ppgtt->pd;
> +
> + switch (vm->top) {
> + case 3:
> + pd = i915_pd_entry(pd, gen8_pd_index(idx, 3));
> + /* fall through */
You fell through for a break!
What could you be planning next?
if (vm->top == 2)
return ppgtt->pd;
else
return i915_pd_entry(ppgtt->pd, gen8_pd_index(idx, vm->top));
> + case 2:
> + break;
> +
> + default:
> + GEM_BUG_ON(vm->top);
> + }
> +
> + return pd;
> +}
> +
> +static inline struct i915_page_directory *
> +gen8_pdp_for_page_address(struct i915_address_space * const vm, const u64
> addr)
> +{
> + return gen8_pdp_for_page_index(vm, addr >> GEN8_PTE_SHIFT);
> +}
> +
> static void __gen8_ppgtt_cleanup(struct i915_address_space *vm,
> struct i915_page_directory *pd,
> int count, int lvl)
> @@ -1182,23 +1208,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_ppgtt *ppgtt,
> return idx;
> }
>
> -static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm,
> - struct i915_vma *vma,
> - enum i915_cache_level cache_level,
> - u32 flags)
> -{
> - struct i915_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
> - struct sgt_dma iter = sgt_dma(vma);
> -
> - gen8_ppgtt_insert_pte_entries(ppgtt, ppgtt->pd, &iter,
> - vma->node.start >> GEN8_PTE_SHIFT,
> - cache_level, flags);
> -
> - vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
> -}
> -
> static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
> - struct i915_page_directory *pml4,
>struct sgt_dma *iter,
>enum i915_cache_level cache_level,
>u32 flags)
> @@ -1208,9 +1218,9 @@ static void gen8_ppgtt_insert_huge_entries(struct
> i915_vma *vma,
> dma_addr_t rem = iter->sg->length;
>
> do {
> - struct i915_page_directory *pdp =
> - i915_pd_entry(pml4, __gen8_pte_index(start, 3));
> - struct i915_page_directory *pd =
> + struct i915_page_directory * const pdp =
> + gen8_pdp_for_page_address(vma->vm, start);
> + struct i915_page_directory * const pd =
> i915_pd_entry(pdp, __gen8_pte_index(start, 2));
> gen8_pte_t encode = pte_encode;
> unsigned int maybe_64K = -1;
> @@ -1316,26 +1326,31 @@ static void gen8_ppgtt_insert_huge_entries(struct
> i915_vma *vma,
> } while (iter->sg);
> }
>
> -static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
> - struct i915_vma *vma,
> - enum i915_cache_level cache_level,
> - u32 flags)
> +static void gen8_ppgtt_insert(struct i915_address_space *vm,
> + struct i915_vma *vma,
> + enum i915_cache_level cache_level,
> + u32 flags)
> {
> - struct i915_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
> + struct i915_ppgtt * const ppgtt = i915_vm_to_ppgtt(vm);
> struct sgt_dma iter = sgt_dma(vma);
> - struct i915_page_directory * const pml4 = ppgtt->pd;
>
> if (vma->page_sizes.sg > I915_GTT_PAGE_SIZE) {
It's worth having a GEM_BUG_ON(!i915_vm_is_4lvl()) here I think
Or we use (vma->page_size.sg & vm->page_sizes) & ~SZ_4K
> - gen8_ppgtt_insert_huge_entries(vma, pml4, &iter, cache_level,
> + gen8_ppgtt_insert_huge_entries(vma, &iter, cache_level,
>flags);
> } else {
>
Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic eviction
On Thu, Aug 15, 2019 at 12:48 PM Matthew Auld wrote: > > On Tue, 30 Jul 2019 at 17:26, Daniel Vetter wrote: > > > > On Thu, Jun 27, 2019 at 09:55:59PM +0100, Matthew Auld wrote: > > > Support basic eviction for regions. > > > > > > Signed-off-by: Matthew Auld > > > Cc: Joonas Lahtinen > > > Cc: Abdiel Janulgue > > > > So from a very high level this looks like it was largely modelled after > > i915_gem_shrink.c and not i915_gem_evict.c (our other "make room, we're > > running out of stuff" code). Any specific reasons? > > IIRC I think it was originally based on the patches that exposed > stolen-memory to userspace from a few years ago. > > > > > I think i915_gem_evict is a lot closer match for what we want for vram (it > > started out to manage severely limitted GTT on gen2/3/4) after all. With > > the complication that we'll have to manage physical memory with multiple > > virtual mappings of it on top, so unfortunately we can't just reuse the > > locking patter Chris has come up with in his struct_mutex-removal branch. > > But at least conceptually it should be a lot closer. > > When you say make it more like i915_gem_evict, what does that mean? > Are you talking about the eviction roster stuff, or the > placement/locking of the eviction logic, with it being deep down in > get_pages? So there's kinda two aspects here that I meant. First is the high-level approach of the shrinker, which is a direct reflection of core mm low memory handling principles: Core mm just tries to equally shrink everyone when there's low memory, which is managed by watermarks, and a few other tricks. This is all only best-effort, and if multiple threads want a lot of memory at the same time then it's all going to fail with ENOMEM. On gpus otoh, and what we do in i915_gem_eviction.c for gtt (and very much needed with the tiny gtt for everything in gen2/3/4/5) is that when we run out of space, we stall, throw out everyone else, and have exclusive access to the entire gpu space. Then the next batchbuffer goes through the same dance. With this you guarantee that if you have a series of batchbuffers which all need e.g. 60% of lmem, they will all be able to execute. With the shrinker-style of low-memory handling eventually you're unlucky, both threads will only get up to 50%, fail with ENOSPC, and userspace crashes. Which is not good. The other bit is locking. Since we need to free pages from the shrinker there's tricky locking rules involved. Worse, we cannot back off from the shrinker down to e.g. the kmalloc or alloc_pages called that put us into reclaim. Which means the usual deadlock avoidance trick of having a slowpath where you first drop all the locks, then reacquire them in the right order doesn't work - in some cases the caller of kmalloc or alloc_pages could be holding a lock that we'd need to unlock first. Hence why the shrinker uses the best-effort-might-fail solution of trylocks, encoded in shrinker_lock. But for lmem we don't have such an excuse, because it's all our own code. The locking design can (and should!) assume that it can get out of any deadlock and always acquire all the locks it needs. Without that you can't achive the first part about guaranteeing execution of batches which collectively need more than 100% of lmem, but individually all fit. As an example if you look at the amdgpu command submission ioctl, that passes around ttm_operation_ctx which tracks a few things about locks and other bits, and if they hit a possible deadlock situation they can unwind the entire CS and restart by taking the locks in the right order. I thought I typed that up somewhere, but I guess it got lost ... Cheers, Daniel > > > > > But I might be entirely off the track with reconstructing how this code > > came to be, so please elaborate a bit. > > > > Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic eviction
On Thu, Aug 15, 2019 at 4:26 PM Daniel Vetter wrote: > On Thu, Aug 15, 2019 at 12:48 PM Matthew Auld > wrote: > > > > On Tue, 30 Jul 2019 at 17:26, Daniel Vetter wrote: > > > > > > On Thu, Jun 27, 2019 at 09:55:59PM +0100, Matthew Auld wrote: > > > > Support basic eviction for regions. > > > > > > > > Signed-off-by: Matthew Auld > > > > Cc: Joonas Lahtinen > > > > Cc: Abdiel Janulgue > > > > > > So from a very high level this looks like it was largely modelled after > > > i915_gem_shrink.c and not i915_gem_evict.c (our other "make room, we're > > > running out of stuff" code). Any specific reasons? > > > > IIRC I think it was originally based on the patches that exposed > > stolen-memory to userspace from a few years ago. Forgot to add this: Yeah, I guess those have been best-effort to at most. Or at least I never really looked at them seriously since the open source userspace never went anywhere. -Daniel > > > I think i915_gem_evict is a lot closer match for what we want for vram (it > > > started out to manage severely limitted GTT on gen2/3/4) after all. With > > > the complication that we'll have to manage physical memory with multiple > > > virtual mappings of it on top, so unfortunately we can't just reuse the > > > locking patter Chris has come up with in his struct_mutex-removal branch. > > > But at least conceptually it should be a lot closer. > > > > When you say make it more like i915_gem_evict, what does that mean? > > Are you talking about the eviction roster stuff, or the > > placement/locking of the eviction logic, with it being deep down in > > get_pages? > > So there's kinda two aspects here that I meant. > > First is the high-level approach of the shrinker, which is a direct > reflection of core mm low memory handling principles: Core mm just > tries to equally shrink everyone when there's low memory, which is > managed by watermarks, and a few other tricks. This is all only > best-effort, and if multiple threads want a lot of memory at the same > time then it's all going to fail with ENOMEM. > > On gpus otoh, and what we do in i915_gem_eviction.c for gtt (and very > much needed with the tiny gtt for everything in gen2/3/4/5) is that > when we run out of space, we stall, throw out everyone else, and have > exclusive access to the entire gpu space. Then the next batchbuffer > goes through the same dance. With this you guarantee that if you have > a series of batchbuffers which all need e.g. 60% of lmem, they will > all be able to execute. With the shrinker-style of low-memory handling > eventually you're unlucky, both threads will only get up to 50%, fail > with ENOSPC, and userspace crashes. Which is not good. > > The other bit is locking. Since we need to free pages from the > shrinker there's tricky locking rules involved. Worse, we cannot back > off from the shrinker down to e.g. the kmalloc or alloc_pages called > that put us into reclaim. Which means the usual deadlock avoidance > trick of having a slowpath where you first drop all the locks, then > reacquire them in the right order doesn't work - in some cases the > caller of kmalloc or alloc_pages could be holding a lock that we'd > need to unlock first. Hence why the shrinker uses the > best-effort-might-fail solution of trylocks, encoded in shrinker_lock. > > But for lmem we don't have such an excuse, because it's all our own > code. The locking design can (and should!) assume that it can get out > of any deadlock and always acquire all the locks it needs. Without > that you can't achive the first part about guaranteeing execution of > batches which collectively need more than 100% of lmem, but > individually all fit. As an example if you look at the amdgpu command > submission ioctl, that passes around ttm_operation_ctx which tracks a > few things about locks and other bits, and if they hit a possible > deadlock situation they can unwind the entire CS and restart by taking > the locks in the right order. > > I thought I typed that up somewhere, but I guess it got lost ... > > Cheers, Daniel > > > > > > > > > But I might be entirely off the track with reconstructing how this code > > > came to be, so please elaborate a bit. > > > > > > Thanks, Daniel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu, Aug 15, 2019 at 4:38 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 03:12:11PM +0200, Daniel Vetter wrote: > > On Thu, Aug 15, 2019 at 3:04 PM Jason Gunthorpe wrote: > > > > > > On Thu, Aug 15, 2019 at 10:44:29AM +0200, Michal Hocko wrote: > > > > > > > As the oom reaper is the primary guarantee of the oom handling forward > > > > progress it cannot be blocked on anything that might depend on blockable > > > > memory allocations. These are not really easy to track because they > > > > might be indirect - e.g. notifier blocks on a lock which other context > > > > holds while allocating memory or waiting for a flusher that needs memory > > > > to perform its work. > > > > > > But lockdep *does* track all this and fs_reclaim_acquire() was created > > > to solve exactly this problem. > > > > > > fs_reclaim is a lock and it flows through all the usual lockdep > > > schemes like any other lock. Any time the page allocator wants to do > > > something the would deadlock with reclaim it takes the lock. > > > > > > Failure is expressed by a deadlock cycle in the lockdep map, and > > > lockdep can handle arbitary complexity through layers of locks, work > > > queues, threads, etc. > > > > > > What is missing? > > > > Lockdep doens't seen everything by far. E.g. a wait_event will be > > caught by the annotations here, but not by lockdep. > > Sure, but the wait_event might be OK if its progress isn't contingent > on fs_reclaim, ie triggered from interrupt, so why ban it? For normal notifiers sure (but lockdep won't help you proof that at all). For oom_reaper apparently not, but that's really Michal's thing, I have not much idea about that. > > And since we're talking about mmu notifiers here and gpus/dma engines. > > We have dma_fence_wait, which can wait for any hw/driver in the system > > that takes part in shared/zero-copy buffer processing. Which at least > > on the graphics side is everything. This pulls in enormous amounts of > > deadlock potential that lockdep simply is blind about and will never > > see. > > It seems very risky to entagle a notifier widely like that. That's why I've looked into all possible ways to annotate them with debug infrastructure. > It looks pretty sure that notifiers are fs_reclaim, so at a minimum > that wait_event can't be contingent on anything that is doing > GFP_KERNEL or it will deadlock - and blockable doesn't make that sleep > safe. > > Avoiding an uncertain wait_event under notifiers would seem to be the > only reasonable design here.. You have to wait for the gpu to finnish current processing in invalidate_range_start. Otherwise there's no point to any of this really. So the wait_event/dma_fence_wait are unavoidable really. That's also why I'm throwing in the lockdep annotation on top, and why it would be really nice if we somehow can get the cross-release work landed. But it looks like all the people who could make it happen are busy with smeltdown :-/ -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic eviction
> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Daniel Vetter > Sent: Thursday, August 15, 2019 7:27 AM > To: Matthew Auld > Cc: Intel Graphics Development ; Auld, > Matthew > Subject: Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic > eviction > > On Thu, Aug 15, 2019 at 12:48 PM Matthew Auld > wrote: > > > > On Tue, 30 Jul 2019 at 17:26, Daniel Vetter wrote: > > > > > > On Thu, Jun 27, 2019 at 09:55:59PM +0100, Matthew Auld wrote: > > > > Support basic eviction for regions. > > > > > > > > Signed-off-by: Matthew Auld > > > > Cc: Joonas Lahtinen > > > > Cc: Abdiel Janulgue > > > > > > So from a very high level this looks like it was largely modelled > > > after i915_gem_shrink.c and not i915_gem_evict.c (our other "make > > > room, we're running out of stuff" code). Any specific reasons? > > > > IIRC I think it was originally based on the patches that exposed > > stolen-memory to userspace from a few years ago. > > > > > > > > I think i915_gem_evict is a lot closer match for what we want for > > > vram (it started out to manage severely limitted GTT on gen2/3/4) > > > after all. With the complication that we'll have to manage physical > > > memory with multiple virtual mappings of it on top, so unfortunately > > > we can't just reuse the locking patter Chris has come up with in his > struct_mutex-removal branch. > > > But at least conceptually it should be a lot closer. > > > > When you say make it more like i915_gem_evict, what does that mean? > > Are you talking about the eviction roster stuff, or the > > placement/locking of the eviction logic, with it being deep down in > > get_pages? > > So there's kinda two aspects here that I meant. > > First is the high-level approach of the shrinker, which is a direct > reflection of > core mm low memory handling principles: Core mm just tries to equally > shrink everyone when there's low memory, which is managed by > watermarks, and a few other tricks. This is all only best-effort, and if > multiple > threads want a lot of memory at the same time then it's all going to fail with > ENOMEM. > > On gpus otoh, and what we do in i915_gem_eviction.c for gtt (and very much > needed with the tiny gtt for everything in gen2/3/4/5) is that when we run > out of space, we stall, throw out everyone else, and have exclusive access to > the entire gpu space. Then the next batchbuffer goes through the same > dance. With this you guarantee that if you have a series of batchbuffers > which all need e.g. 60% of lmem, they will all be able to execute. With the > shrinker-style of low-memory handling eventually you're unlucky, both > threads will only get up to 50%, fail with ENOSPC, and userspace crashes. > Which is not good. > > The other bit is locking. Since we need to free pages from the shrinker > there's tricky locking rules involved. Worse, we cannot back off from the > shrinker down to e.g. the kmalloc or alloc_pages called that put us into > reclaim. Which means the usual deadlock avoidance trick of having a > slowpath where you first drop all the locks, then reacquire them in the right > order doesn't work - in some cases the caller of kmalloc or alloc_pages could > be holding a lock that we'd need to unlock first. Hence why the shrinker uses > the best-effort-might-fail solution of trylocks, encoded in shrinker_lock. > > But for lmem we don't have such an excuse, because it's all our own code. > The locking design can (and should!) assume that it can get out of any > deadlock and always acquire all the locks it needs. Without that you can't > achive the first part about guaranteeing execution of batches which > collectively need more than 100% of lmem, but individually all fit. As an > example if you look at the amdgpu command submission ioctl, that passes > around ttm_operation_ctx which tracks a few things about locks and other > bits, and if they hit a possible deadlock situation they can unwind the entire > CS and restart by taking the locks in the right order. Thank you for the explanation. What does our 'struct_mutex' protect for exactly? As example, I see when blitter engine functions are called, we hold 'struct_mutex" first. Can we replace 'struct_mutex' with some fine-grain locks so that we can lock obj->mm.lock first, and then lock these fine-grain locks? I need some background info about 'struct_mutex' design. --CQ > > I thought I typed that up somewhere, but I guess it got lost ... > > Cheers, Daniel > > > > > > > > > But I might be entirely off the track with reconstructing how this > > > code came to be, so please elaborate a bit. > > > > > > Thanks, Daniel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _
Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic eviction
Quoting Matthew Auld (2019-08-15 11:48:04) > On Tue, 30 Jul 2019 at 17:26, Daniel Vetter wrote: > > > > On Thu, Jun 27, 2019 at 09:55:59PM +0100, Matthew Auld wrote: > > > Support basic eviction for regions. > > > > > > Signed-off-by: Matthew Auld > > > Cc: Joonas Lahtinen > > > Cc: Abdiel Janulgue > > > > So from a very high level this looks like it was largely modelled after > > i915_gem_shrink.c and not i915_gem_evict.c (our other "make room, we're > > running out of stuff" code). Any specific reasons? > > IIRC I think it was originally based on the patches that exposed > stolen-memory to userspace from a few years ago. > > > > > I think i915_gem_evict is a lot closer match for what we want for vram (it > > started out to manage severely limitted GTT on gen2/3/4) after all. With > > the complication that we'll have to manage physical memory with multiple > > virtual mappings of it on top, so unfortunately we can't just reuse the > > locking patter Chris has come up with in his struct_mutex-removal branch. > > But at least conceptually it should be a lot closer. > > When you say make it more like i915_gem_evict, what does that mean? > Are you talking about the eviction roster stuff, or the > placement/locking of the eviction logic, with it being deep down in > get_pages? The biggest difference would be the lack of region coalescing; the eviction code only tries to free what would result in a successful allocation. With the order being put into the scanner somewhat relevant, in practice, fragmentation effects cause the range search to be somewhat slow and we much prefer the random replacement -- while harmful, it is not biased as to who it harms, and so is consistent overhead. However, since you don't need to find a slot inside a small range within a few million objects, I would expect LRU or even MRU (recently used objects in games tend to be more ephemeral and so made good eviction targets, at least according to John Carmack back in the day) to require fewer major faults. https://github.com/ESWAT/john-carmack-plan-archive/blob/master/by_day/johnc_plan_2307.txt You would need a very similar scanner to keep a journal of the potential frees from which to track the coalescing (slightly more complicated due to the disjoint nature of the buddy merges). One suspects that adding the scanner would shape the buddy_nodes more towards drm_mm_nodes. This is also a case where real world testing of a thrashing load beats simulation. So just make sure the eviction doesn't stall the entire GPU and submission pipeline and you will be forgiven most transgressions. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu 15-08-19 11:12:19, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 03:21:27PM +0200, Michal Hocko wrote:
> > On Thu 15-08-19 09:23:44, Jason Gunthorpe wrote:
> > > On Thu, Aug 15, 2019 at 08:58:29AM +0200, Daniel Vetter wrote:
> > > > On Wed, Aug 14, 2019 at 08:58:05PM -0300, Jason Gunthorpe wrote:
> > > > > On Wed, Aug 14, 2019 at 10:20:24PM +0200, Daniel Vetter wrote:
> > > > > > In some special cases we must not block, but there's not a
> > > > > > spinlock, preempt-off, irqs-off or similar critical section already
> > > > > > that arms the might_sleep() debug checks. Add a
> > > > > > non_block_start/end()
> > > > > > pair to annotate these.
> > > > > >
> > > > > > This will be used in the oom paths of mmu-notifiers, where blocking
> > > > > > is
> > > > > > not allowed to make sure there's forward progress. Quoting Michal:
> > > > > >
> > > > > > "The notifier is called from quite a restricted context -
> > > > > > oom_reaper -
> > > > > > which shouldn't depend on any locks or sleepable conditionals. The
> > > > > > code
> > > > > > should be swift as well but we mostly do care about it to make a
> > > > > > forward
> > > > > > progress. Checking for sleepable context is the best thing we could
> > > > > > come
> > > > > > up with that would describe these demands at least partially."
> > > > >
> > > > > But this describes fs_reclaim_acquire() - is there some reason we are
> > > > > conflating fs_reclaim with non-sleeping?
> > > >
> > > > No idea why you tie this into fs_reclaim. We can definitly sleep in
> > > > there,
> > > > and for e.g. kswapd (which also wraps everything in fs_reclaim) we're
> > > > event supposed to I thought. To make sure we can get at the last bit of
> > > > memory by flushing all the queues and waiting for everything to be
> > > > cleaned
> > > > out.
> > >
> > > AFAIK the point of fs_reclaim is to prevent "indirect dependency upon
> > > the page allocator" ie a justification that was given this !blockable
> > > stuff.
> > >
> > > For instance:
> > >
> > > fs_reclaim_acquire()
> > > kmalloc(GFP_KERNEL) <- lock dep assertion
> > >
> > > And further, Michal's concern about indirectness through locks is also
> > > handled by lockdep:
> > >
> > >CPU0 CPU1
> > > mutex_lock()
> > > kmalloc(GFP_KERNEL)
> > > mutex_unlock()
> > > fs_reclaim_acquire()
> > > mutex_lock() <- lock dep assertion
> > >
> > > In other words, to prevent recursion into the page allocator you use
> > > fs_reclaim_acquire(), and lockdep verfies it in its usual robust way.
> >
> > fs_reclaim_acquire is about FS/IO recursions IIUC. We are talking about
> > any !GFP_NOWAIT allocation context here and any {in}direct dependency on
> > it.
>
> AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and
> __GFP_DIRECT_RECLAIM..
>
> This matches the existing test in __need_fs_reclaim() - so if you are
> OK with GFP_NOFS, aka __GFP_IO which triggers try_to_compact_pages(),
> allocations during OOM, then I think fs_reclaim already matches what
> you described?
No GFP_NOFS is equally bad. Please read my other email explaining what
the oom_reaper actually requires. In short no blocking on direct or
indirect dependecy on memory allocation that might sleep. If you can
express that in the existing lockdep machinery. All fine. But then
consider deployments where lockdep is no-no because of the overhead.
> > No, non-blocking is a very coarse approximation of what we really need.
> > But it should give us even a stronger condition. Essentially any sleep
> > other than a preemption shouldn't be allowed in that context.
>
> But it is a nonsense API to give the driver invalidate_range_start,
> the blocking alternative to the non-blocking invalidate_range and then
> demand it to be non-blocking.
>
> Inspecting the code, no drivers are actually able to progress their
> side in non-blocking mode.
>
> The best we got was drivers tested the VA range and returned success
> if they had no interest. Which is a big win to be sure, but it looks
> like getting any more is not really posssible.
And that is already a great win! Because many notifiers only do care
about particular mappings. Please note that backing off unconditioanlly
will simply cause that the oom reaper will have to back off not doing
any tear down anything.
> However, we could (probably even should) make the drivers fs_reclaim
> safe.
>
> If that is enough to guarantee progress of OOM, then lets consider
> something like using current_gfp_context() to force PF_MEMALLOC_NOFS
> allocation behavior on the driver callback and lockdep to try and keep
> pushing on the the debugging, and dropping !blocking.
How are you going to enforce indirect dependency? E.g. a lock that is
also used in other context which depend on sleepable memory allocation
to move forward.
Really, this
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gtt: Fold gen8 insertions into one
== Series Details ==
Series: drm/i915/gtt: Fold gen8 insertions into one
URL : https://patchwork.freedesktop.org/series/65258/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14030
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14030/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14030:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_chamelium@hdmi-hpd-fast:
- {fi-icl-u4}:[FAIL][1] ([fdo#111045]) -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14030/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
Known issues
Here are the changes found in Patchwork_14030 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-cml-u: [PASS][3] -> [INCOMPLETE][4] ([fdo#110566])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14030/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][5] -> [INCOMPLETE][6] ([fdo#107718])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14030/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
Possible fixes
* igt@gem_ctx_switch@rcs0:
- {fi-icl-guc}: [INCOMPLETE][7] ([fdo#107713]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14030/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: [WARN][9] ([fdo#109380]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14030/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][11] ([fdo#111045]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14030/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u: [SKIP][13] ([fdo#109271]) -> [PASS][14] +23 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14030/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
Participating hosts (53 -> 44)
--
Additional (1): fi-gdg-551
Missing(10): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-hsw-4770 fi-ivb-3770 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6712 -> Patchwork_14030
CI-20190529: 20190529
CI_DRM_6712: cd7b3a5a9d3b20684a62b8c1a33707c162ee3629 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14030: b6b280384ced9ad16e90cfb31bc2eba1f60834c5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b6b280384ced drm/i915/gtt: Fold gen8 insertions into one
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14030/
___
Intel-gf
Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic eviction
On Thu, Aug 15, 2019 at 4:58 PM Tang, CQ wrote: > > > > > -Original Message- > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > > Of Daniel Vetter > > Sent: Thursday, August 15, 2019 7:27 AM > > To: Matthew Auld > > Cc: Intel Graphics Development ; Auld, > > Matthew > > Subject: Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic > > eviction > > > > On Thu, Aug 15, 2019 at 12:48 PM Matthew Auld > > wrote: > > > > > > On Tue, 30 Jul 2019 at 17:26, Daniel Vetter wrote: > > > > > > > > On Thu, Jun 27, 2019 at 09:55:59PM +0100, Matthew Auld wrote: > > > > > Support basic eviction for regions. > > > > > > > > > > Signed-off-by: Matthew Auld > > > > > Cc: Joonas Lahtinen > > > > > Cc: Abdiel Janulgue > > > > > > > > So from a very high level this looks like it was largely modelled > > > > after i915_gem_shrink.c and not i915_gem_evict.c (our other "make > > > > room, we're running out of stuff" code). Any specific reasons? > > > > > > IIRC I think it was originally based on the patches that exposed > > > stolen-memory to userspace from a few years ago. > > > > > > > > > > > I think i915_gem_evict is a lot closer match for what we want for > > > > vram (it started out to manage severely limitted GTT on gen2/3/4) > > > > after all. With the complication that we'll have to manage physical > > > > memory with multiple virtual mappings of it on top, so unfortunately > > > > we can't just reuse the locking patter Chris has come up with in his > > struct_mutex-removal branch. > > > > But at least conceptually it should be a lot closer. > > > > > > When you say make it more like i915_gem_evict, what does that mean? > > > Are you talking about the eviction roster stuff, or the > > > placement/locking of the eviction logic, with it being deep down in > > > get_pages? > > > > So there's kinda two aspects here that I meant. > > > > First is the high-level approach of the shrinker, which is a direct > > reflection of > > core mm low memory handling principles: Core mm just tries to equally > > shrink everyone when there's low memory, which is managed by > > watermarks, and a few other tricks. This is all only best-effort, and if > > multiple > > threads want a lot of memory at the same time then it's all going to fail > > with > > ENOMEM. > > > > On gpus otoh, and what we do in i915_gem_eviction.c for gtt (and very much > > needed with the tiny gtt for everything in gen2/3/4/5) is that when we run > > out of space, we stall, throw out everyone else, and have exclusive access > > to > > the entire gpu space. Then the next batchbuffer goes through the same > > dance. With this you guarantee that if you have a series of batchbuffers > > which all need e.g. 60% of lmem, they will all be able to execute. With the > > shrinker-style of low-memory handling eventually you're unlucky, both > > threads will only get up to 50%, fail with ENOSPC, and userspace crashes. > > Which is not good. > > > > The other bit is locking. Since we need to free pages from the shrinker > > there's tricky locking rules involved. Worse, we cannot back off from the > > shrinker down to e.g. the kmalloc or alloc_pages called that put us into > > reclaim. Which means the usual deadlock avoidance trick of having a > > slowpath where you first drop all the locks, then reacquire them in the > > right > > order doesn't work - in some cases the caller of kmalloc or alloc_pages > > could > > be holding a lock that we'd need to unlock first. Hence why the shrinker > > uses > > the best-effort-might-fail solution of trylocks, encoded in shrinker_lock. > > > > But for lmem we don't have such an excuse, because it's all our own code. > > The locking design can (and should!) assume that it can get out of any > > deadlock and always acquire all the locks it needs. Without that you can't > > achive the first part about guaranteeing execution of batches which > > collectively need more than 100% of lmem, but individually all fit. As an > > example if you look at the amdgpu command submission ioctl, that passes > > around ttm_operation_ctx which tracks a few things about locks and other > > bits, and if they hit a possible deadlock situation they can unwind the > > entire > > CS and restart by taking the locks in the right order. > > Thank you for the explanation. > > What does our 'struct_mutex' protect for exactly? As example, I see when > blitter engine functions are called, we hold 'struct_mutex" first. > > Can we replace 'struct_mutex' with some fine-grain locks so that we can lock > obj->mm.lock first, and then lock these fine-grain locks? Sure. With lots of efforts. > I need some background info about 'struct_mutex' design. There's not really a design behind it, it's just 10+ years of evolution. -Daniel > --CQ > > > > > I thought I typed that up somewhere, but I guess it got lost ... > > > > Cheers, Daniel > > > > > > > > > > > > > But I might be entirely off the track with reconstructing how
Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic eviction
On Thu, Aug 15, 2019 at 5:26 PM Chris Wilson wrote: > > Quoting Matthew Auld (2019-08-15 11:48:04) > > On Tue, 30 Jul 2019 at 17:26, Daniel Vetter wrote: > > > > > > On Thu, Jun 27, 2019 at 09:55:59PM +0100, Matthew Auld wrote: > > > > Support basic eviction for regions. > > > > > > > > Signed-off-by: Matthew Auld > > > > Cc: Joonas Lahtinen > > > > Cc: Abdiel Janulgue > > > > > > So from a very high level this looks like it was largely modelled after > > > i915_gem_shrink.c and not i915_gem_evict.c (our other "make room, we're > > > running out of stuff" code). Any specific reasons? > > > > IIRC I think it was originally based on the patches that exposed > > stolen-memory to userspace from a few years ago. > > > > > > > > I think i915_gem_evict is a lot closer match for what we want for vram (it > > > started out to manage severely limitted GTT on gen2/3/4) after all. With > > > the complication that we'll have to manage physical memory with multiple > > > virtual mappings of it on top, so unfortunately we can't just reuse the > > > locking patter Chris has come up with in his struct_mutex-removal branch. > > > But at least conceptually it should be a lot closer. > > > > When you say make it more like i915_gem_evict, what does that mean? > > Are you talking about the eviction roster stuff, or the > > placement/locking of the eviction logic, with it being deep down in > > get_pages? > > The biggest difference would be the lack of region coalescing; the > eviction code only tries to free what would result in a successful > allocation. With the order being put into the scanner somewhat relevant, > in practice, fragmentation effects cause the range search to be somewhat > slow and we much prefer the random replacement -- while harmful, it is > not biased as to who it harms, and so is consistent overhead. However, > since you don't need to find a slot inside a small range within a few > million objects, I would expect LRU or even MRU (recently used objects > in games tend to be more ephemeral and so made good eviction targets, at > least according to John Carmack back in the day) to require fewer major > faults. > https://github.com/ESWAT/john-carmack-plan-archive/blob/master/by_day/johnc_plan_2307.txt > > You would need a very similar scanner to keep a journal of the potential > frees from which to track the coalescing (slightly more complicated due > to the disjoint nature of the buddy merges). One suspects that adding > the scanner would shape the buddy_nodes more towards drm_mm_nodes. > > This is also a case where real world testing of a thrashing load beats > simulation. So just make sure the eviction doesn't stall the entire GPU > and submission pipeline and you will be forgiven most transgressions. Yeah the fancy roster is definitely not on the wishlist until we have this all optimized already. And even then it's probably better to not be fancy, since we don't really need a contiguous block for pretty much anything. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu, Aug 15, 2019 at 5:10 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote: > > > You have to wait for the gpu to finnish current processing in > > invalidate_range_start. Otherwise there's no point to any of this > > really. So the wait_event/dma_fence_wait are unavoidable really. > > I don't envy your task :| > > But, what you describe sure sounds like a 'registration cache' model, > not the 'shadow pte' model of coherency. > > The key difference is that a regirstationcache is allowed to become > incoherent with the VMA's because it holds page pins. It is a > programming bug in userspace to change VA mappings via mmap/munmap/etc > while the device is working on that VA, but it does not harm system > integrity because of the page pin. > > The cache ensures that each initiated operation sees a DMA setup that > matches the current VA map when the operation is initiated and allows > expensive device DMA setups to be re-used. > > A 'shadow pte' model (ie hmm) *really* needs device support to > directly block DMA access - ie trigger 'device page fault'. ie the > invalidate_start should inform the device to enter a fault mode and > that is it. If the device can't do that, then the driver probably > shouldn't persue this level of coherency. The driver would quickly get > into the messy locking problems like dma_fence_wait from a notifier. > > It is important to identify what model you are going for as defining a > 'registration cache' coherence expectation allows the driver to skip > blocking in invalidate_range_start. All it does is invalidate the > cache so that future operations pick up the new VA mapping. > > Intel's HFI RDMA driver uses this model extensively, and I think it is > well proven, within some limitations of course. > > At least, 'registration cache' is the only use model I know of where > it is acceptable to skip invalidate_range_end. I'm not really well versed in the details of our userptr, but both amdgpu and i915 wait for the gpu to complete from invalidate_range_start. Jerome has at least looked a lot at the amdgpu one, so maybe he can explain what exactly it is we're doing ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote: > > > You have to wait for the gpu to finnish current processing in > > invalidate_range_start. Otherwise there's no point to any of this > > really. So the wait_event/dma_fence_wait are unavoidable really. > > I don't envy your task :| > > But, what you describe sure sounds like a 'registration cache' model, > not the 'shadow pte' model of coherency. > > The key difference is that a regirstationcache is allowed to become > incoherent with the VMA's because it holds page pins. It is a > programming bug in userspace to change VA mappings via mmap/munmap/etc > while the device is working on that VA, but it does not harm system > integrity because of the page pin. > > The cache ensures that each initiated operation sees a DMA setup that > matches the current VA map when the operation is initiated and allows > expensive device DMA setups to be re-used. > > A 'shadow pte' model (ie hmm) *really* needs device support to > directly block DMA access - ie trigger 'device page fault'. ie the > invalidate_start should inform the device to enter a fault mode and > that is it. If the device can't do that, then the driver probably > shouldn't persue this level of coherency. The driver would quickly get > into the messy locking problems like dma_fence_wait from a notifier. I think here we do not agree on the hardware requirement. For GPU we will always need to be able to wait for some GPU fence from inside the notifier callback, there is just no way around that for many of the GPUs today (i do not see any indication of that changing). Driver should avoid lock complexity by using wait queue so that the driver notifier callback can wait without having to hold some driver lock. However there will be at least one lock needed to update the internal driver state for the range being invalidated. That lock is just the device driver page table lock for the GPU page table associated with the mm_struct. In all GPU driver so far it is a short lived lock and nothing blocking is done while holding it (it is just about updating page table directory really wether it is filling it or clearing it). > > It is important to identify what model you are going for as defining a > 'registration cache' coherence expectation allows the driver to skip > blocking in invalidate_range_start. All it does is invalidate the > cache so that future operations pick up the new VA mapping. > > Intel's HFI RDMA driver uses this model extensively, and I think it is > well proven, within some limitations of course. > > At least, 'registration cache' is the only use model I know of where > it is acceptable to skip invalidate_range_end. Here GPU are not in the registration cache model, i know it might looks like it because of GUP but GUP was use just because hmm did not exist at the time. Cheers, Jérôme ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gen11: Allow usage of all GPIO pins
Our pin mapping tables for ICP and MCC currently only list the standard
GPIO pins used for various output ports. Even through ICP's standard
pin usage only utilizes pins 1, 2, and 9-12, and MCC's standard pin
usage only uses pins 1, 2, and 9, these platforms do still have GPIO
registers to address pins in the range 1-3 and 9-14. OEM's may remap
GPIO usage in non-standard ways (and provide the actual mapping via VBT
settings), so we shouldn't exclude pins on these platforms just because
they aren't part of the standard mappings.
TGP's standard pin tables contains all the possible pins, so let's
rename them to "icp" and use them for all PCH >= PCH_ICP. This will
prevent intel_gmbus_is_valid_pin from rejecting non-standard pin usage
that an OEM specifies via the VBT.
Note that this will cause pin 9 to be labeled as "tc1" instead of "dpc"
in debug messages on platforms with the MCC PCH, but that may actually
help avoid confusion since the text strings will now be the same on all
gen11+ platforms instead of being different on just EHL.
Bspec: 8417
Cc: José Roberto de Souza
Cc: Lucas De Marchi
Cc: Vivek Kasireddy
Cc: Jani Nikula
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_bios.c | 23 +-
drivers/gpu/drm/i915/display/intel_gmbus.c | 27 ++
2 files changed, 3 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index b416b394b641..ed608f2df130 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1341,21 +1341,6 @@ static const u8 cnp_ddc_pin_map[] = {
};
static const u8 icp_ddc_pin_map[] = {
- [ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
- [ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
- [ICL_DDC_BUS_PORT_1] = GMBUS_PIN_9_TC1_ICP,
- [ICL_DDC_BUS_PORT_2] = GMBUS_PIN_10_TC2_ICP,
- [ICL_DDC_BUS_PORT_3] = GMBUS_PIN_11_TC3_ICP,
- [ICL_DDC_BUS_PORT_4] = GMBUS_PIN_12_TC4_ICP,
-};
-
-static const u8 mcc_ddc_pin_map[] = {
- [MCC_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
- [MCC_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
- [MCC_DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
-};
-
-static const u8 tgp_ddc_pin_map[] = {
[ICL_DDC_BUS_DDI_A] = GMBUS_PIN_1_BXT,
[ICL_DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
[TGL_DDC_BUS_DDI_C] = GMBUS_PIN_3_BXT,
@@ -1372,13 +1357,7 @@ static u8 map_ddc_pin(struct drm_i915_private *dev_priv,
u8 vbt_pin)
const u8 *ddc_pin_map;
int n_entries;
- if (HAS_PCH_TGP(dev_priv)) {
- ddc_pin_map = tgp_ddc_pin_map;
- n_entries = ARRAY_SIZE(tgp_ddc_pin_map);
- } else if (HAS_PCH_MCC(dev_priv)) {
- ddc_pin_map = mcc_ddc_pin_map;
- n_entries = ARRAY_SIZE(mcc_ddc_pin_map);
- } else if (HAS_PCH_ICP(dev_priv)) {
+ if (INTEL_PCH_ID(dev_priv) >= PCH_ICP) {
ddc_pin_map = icp_ddc_pin_map;
n_entries = ARRAY_SIZE(icp_ddc_pin_map);
} else if (HAS_PCH_CNP(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/display/intel_gmbus.c
b/drivers/gpu/drm/i915/display/intel_gmbus.c
index 1e27b18aa3fc..3ac8a5c0b4b5 100644
--- a/drivers/gpu/drm/i915/display/intel_gmbus.c
+++ b/drivers/gpu/drm/i915/display/intel_gmbus.c
@@ -80,21 +80,6 @@ static const struct gmbus_pin gmbus_pins_cnp[] = {
};
static const struct gmbus_pin gmbus_pins_icp[] = {
- [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
- [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
- [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOJ },
- [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOK },
- [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOL },
- [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOM },
-};
-
-static const struct gmbus_pin gmbus_pins_mcc[] = {
- [GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
- [GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
- [GMBUS_PIN_9_TC1_ICP] = { "dpc", GPIOJ },
-};
-
-static const struct gmbus_pin gmbus_pins_tgp[] = {
[GMBUS_PIN_1_BXT] = { "dpa", GPIOB },
[GMBUS_PIN_2_BXT] = { "dpb", GPIOC },
[GMBUS_PIN_3_BXT] = { "dpc", GPIOD },
@@ -110,11 +95,7 @@ static const struct gmbus_pin gmbus_pins_tgp[] = {
static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
unsigned int pin)
{
- if (HAS_PCH_TGP(dev_priv))
- return &gmbus_pins_tgp[pin];
- else if (HAS_PCH_MCC(dev_priv))
- return &gmbus_pins_mcc[pin];
- else if (HAS_PCH_ICP(dev_priv))
+ if (INTEL_PCH_ID(dev_priv) >= PCH_ICP)
return &gmbus_pins_icp[pin];
else if (HAS_PCH_CNP(dev_priv))
return &gmbus_pins_cnp[pin];
@@ -133,11 +114,7 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private
*dev_priv,
{
unsigned int size;
- if (HAS_PCH_TGP(dev_priv))
- size = ARRAY_SIZE(gmbus_pins_tgp);
- else if (HAS_PCH_MCC(dev_priv))
- siz
Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic eviction
> -Original Message- > From: Daniel Vetter [mailto:dan...@ffwll.ch] > Sent: Thursday, August 15, 2019 9:21 AM > To: Tang, CQ > Cc: Matthew Auld ; Intel Graphics > Development ; Auld, Matthew > > Subject: Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support basic > eviction > > On Thu, Aug 15, 2019 at 4:58 PM Tang, CQ wrote: > > > > > > > > > -Original Message- > > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On > > > Behalf Of Daniel Vetter > > > Sent: Thursday, August 15, 2019 7:27 AM > > > To: Matthew Auld > > > Cc: Intel Graphics Development ; > > > Auld, Matthew > > > Subject: Re: [Intel-gfx] [PATCH v2 03/37] drm/i915/region: support > > > basic eviction > > > > > > On Thu, Aug 15, 2019 at 12:48 PM Matthew Auld > > > wrote: > > > > > > > > On Tue, 30 Jul 2019 at 17:26, Daniel Vetter wrote: > > > > > > > > > > On Thu, Jun 27, 2019 at 09:55:59PM +0100, Matthew Auld wrote: > > > > > > Support basic eviction for regions. > > > > > > > > > > > > Signed-off-by: Matthew Auld > > > > > > Cc: Joonas Lahtinen > > > > > > Cc: Abdiel Janulgue > > > > > > > > > > So from a very high level this looks like it was largely > > > > > modelled after i915_gem_shrink.c and not i915_gem_evict.c (our > > > > > other "make room, we're running out of stuff" code). Any specific > reasons? > > > > > > > > IIRC I think it was originally based on the patches that exposed > > > > stolen-memory to userspace from a few years ago. > > > > > > > > > > > > > > I think i915_gem_evict is a lot closer match for what we want > > > > > for vram (it started out to manage severely limitted GTT on > > > > > gen2/3/4) after all. With the complication that we'll have to > > > > > manage physical memory with multiple virtual mappings of it on > > > > > top, so unfortunately we can't just reuse the locking patter > > > > > Chris has come up with in his > > > struct_mutex-removal branch. > > > > > But at least conceptually it should be a lot closer. > > > > > > > > When you say make it more like i915_gem_evict, what does that mean? > > > > Are you talking about the eviction roster stuff, or the > > > > placement/locking of the eviction logic, with it being deep down > > > > in get_pages? > > > > > > So there's kinda two aspects here that I meant. > > > > > > First is the high-level approach of the shrinker, which is a direct > > > reflection of core mm low memory handling principles: Core mm just > > > tries to equally shrink everyone when there's low memory, which is > > > managed by watermarks, and a few other tricks. This is all only > > > best-effort, and if multiple threads want a lot of memory at the > > > same time then it's all going to fail with ENOMEM. > > > > > > On gpus otoh, and what we do in i915_gem_eviction.c for gtt (and > > > very much needed with the tiny gtt for everything in gen2/3/4/5) is > > > that when we run out of space, we stall, throw out everyone else, > > > and have exclusive access to the entire gpu space. Then the next > > > batchbuffer goes through the same dance. With this you guarantee > > > that if you have a series of batchbuffers which all need e.g. 60% of > > > lmem, they will all be able to execute. With the shrinker-style of > > > low-memory handling eventually you're unlucky, both threads will only > get up to 50%, fail with ENOSPC, and userspace crashes. > > > Which is not good. > > > > > > The other bit is locking. Since we need to free pages from the > > > shrinker there's tricky locking rules involved. Worse, we cannot > > > back off from the shrinker down to e.g. the kmalloc or alloc_pages > > > called that put us into reclaim. Which means the usual deadlock > > > avoidance trick of having a slowpath where you first drop all the > > > locks, then reacquire them in the right order doesn't work - in some > > > cases the caller of kmalloc or alloc_pages could be holding a lock > > > that we'd need to unlock first. Hence why the shrinker uses the best- > effort-might-fail solution of trylocks, encoded in shrinker_lock. > > > > > > But for lmem we don't have such an excuse, because it's all our own code. > > > The locking design can (and should!) assume that it can get out of > > > any deadlock and always acquire all the locks it needs. Without that > > > you can't achive the first part about guaranteeing execution of > > > batches which collectively need more than 100% of lmem, but > > > individually all fit. As an example if you look at the amdgpu > > > command submission ioctl, that passes around ttm_operation_ctx which > > > tracks a few things about locks and other bits, and if they hit a > > > possible deadlock situation they can unwind the entire CS and restart by > taking the locks in the right order. > > > > Thank you for the explanation. > > > > What does our 'struct_mutex' protect for exactly? As example, I see when > blitter engine functions are called, we hold 'struct_mutex" first. > > > > Can we replace 'struct_mutex' with some fine-grain
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu, Aug 15, 2019 at 01:56:31PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and > > > __GFP_DIRECT_RECLAIM.. > > > > > > This matches the existing test in __need_fs_reclaim() - so if you are > > > OK with GFP_NOFS, aka __GFP_IO which triggers try_to_compact_pages(), > > > allocations during OOM, then I think fs_reclaim already matches what > > > you described? > > > > No GFP_NOFS is equally bad. Please read my other email explaining what > > the oom_reaper actually requires. In short no blocking on direct or > > indirect dependecy on memory allocation that might sleep. > > It is much easier to follow with some hints on code, so the true > requirement is that the OOM repear not block on GFP_FS and GFP_IO > allocations, great, that constraint is now clear. > > > If you can express that in the existing lockdep machinery. All > > fine. But then consider deployments where lockdep is no-no because > > of the overhead. > > This is all for driver debugging. The point of lockdep is to find all > these paths without have to hit them as actual races, using debug > kernels. > > I don't think we need this kind of debugging on production kernels? > > > > The best we got was drivers tested the VA range and returned success > > > if they had no interest. Which is a big win to be sure, but it looks > > > like getting any more is not really posssible. > > > > And that is already a great win! Because many notifiers only do care > > about particular mappings. Please note that backing off unconditioanlly > > will simply cause that the oom reaper will have to back off not doing > > any tear down anything. > > Well, I'm working to propose that we do the VA range test under core > mmu notifier code that cannot block and then we simply remove the idea > of blockable from drivers using this new 'range notifier'. > > I think this pretty much solves the concern? I am not sure i follow what you propose here ? Like i pointed out in another email for GPU we do need to be able to sleep (we might get lucky and not need too but this is runtime thing) within notifier range_start callback. This has been something allow by notifier since it has been introduced in the kernel. Cheers, Jérôme ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915/uc: Move FW size sanity check back to fetch
From: Michał Winiarski
While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime.
v2: rebased
v3: use __intel_uc_fw_get_upload_size (Daniele)
Signed-off-by: Michał Winiarski
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Jackie Li
Cc: Joonas Lahtinen
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 11 +++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 7 ++-
drivers/gpu/drm/i915/intel_wopcm.c | 14 ++
3 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index d056e1f4bd6d..f4a34ea579fd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -265,6 +265,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
size_t size;
int err;
+ GEM_BUG_ON(!i915->wopcm.size);
GEM_BUG_ON(!intel_uc_fw_supported(uc_fw));
err = i915_inject_load_error(i915, -ENXIO);
@@ -324,6 +325,16 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
goto fail;
}
+ /* Sanity check whether this fw is not larger than whole WOPCM memory */
+ size = __intel_uc_fw_get_upload_size(uc_fw);
+ if (unlikely(size >= i915->wopcm.size)) {
+ dev_warn(dev, "%s firmware %s: invalid size: %zu > %zu\n",
+intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
+size, (size_t)i915->wopcm.size);
+ err = -E2BIG;
+ goto fail;
+ }
+
/* Get version numbers from the CSS header */
switch (uc_fw->type) {
case INTEL_UC_FW_TYPE_GUC:
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index ce8e83128a95..6fa50273c2ce 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -173,6 +173,11 @@ static inline void intel_uc_fw_sanitize(struct intel_uc_fw
*uc_fw)
intel_uc_fw_change_status(uc_fw, INTEL_UC_FIRMWARE_AVAILABLE);
}
+static inline u32 __intel_uc_fw_get_upload_size(struct intel_uc_fw *uc_fw)
+{
+ return sizeof(struct uc_css_header) + uc_fw->ucode_size;
+}
+
/**
* intel_uc_fw_get_upload_size() - Get size of firmware needed to be uploaded.
* @uc_fw: uC firmware.
@@ -186,7 +191,7 @@ static inline u32 intel_uc_fw_get_upload_size(struct
intel_uc_fw *uc_fw)
if (!intel_uc_fw_is_available(uc_fw))
return 0;
- return sizeof(struct uc_css_header) + uc_fw->ucode_size;
+ return __intel_uc_fw_get_upload_size(uc_fw);
}
void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 2bda24200498..2975e00f57f5 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -181,22 +181,12 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
GEM_BUG_ON(!wopcm->size);
GEM_BUG_ON(wopcm->guc.base);
GEM_BUG_ON(wopcm->guc.size);
+ GEM_BUG_ON(guc_fw_size >= wopcm->size);
+ GEM_BUG_ON(huc_fw_size >= wopcm->size);
if (i915_inject_probe_failure(i915))
return;
- if (guc_fw_size >= wopcm->size) {
- DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.",
- guc_fw_size / 1024);
- return;
- }
-
- if (huc_fw_size >= wopcm->size) {
- DRM_ERROR("HuC FW (%uKiB) is too big to fit in WOPCM.",
- huc_fw_size / 1024);
- return;
- }
-
guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
GUC_WOPCM_OFFSET_ALIGNMENT);
if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] More WOPCM fixes
More WOPCM fixes Michal Wajdeczko (4): drm/i915/wopcm: Check WOPCM layout separately from calculations drm/i915/wopcm: Try to use already locked WOPCM layout drm/i915/wopcm: Update error messages drm/i915/wopmc: Fix SPDX tag location Michał Winiarski (1): drm/i915/uc: Move FW size sanity check back to fetch drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 11 ++ drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 7 +- drivers/gpu/drm/i915/intel_wopcm.c | 191 +++ 3 files changed, 143 insertions(+), 66 deletions(-) -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915/wopmc: Fix SPDX tag location
Move SPDX tag to first line, and update year to 2019. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_wopcm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_wopcm.c b/drivers/gpu/drm/i915/intel_wopcm.c index 3b14dd5562ff..53fe1003fba7 100644 --- a/drivers/gpu/drm/i915/intel_wopcm.c +++ b/drivers/gpu/drm/i915/intel_wopcm.c @@ -1,7 +1,6 @@ +// SPDX-License-Identifier: MIT /* - * SPDX-License-Identifier: MIT - * - * Copyright © 2017-2018 Intel Corporation + * Copyright © 2017-2019 Intel Corporation */ #include "intel_wopcm.h" -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Allow usage of all GPIO pins
== Series Details == Series: drm/i915/gen11: Allow usage of all GPIO pins URL : https://patchwork.freedesktop.org/series/65261/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14031 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14031 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14031, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14031: ### IGT changes ### Possible regressions * igt@kms_chamelium@common-hpd-after-suspend: - fi-skl-6700k2: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-6700k2/igt@kms_chamel...@common-hpd-after-suspend.html Warnings * igt@kms_chamelium@hdmi-hpd-fast: - fi-skl-6700k2: [FAIL][3] ([fdo#111407]) -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-6700k2/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-6700k2/igt@kms_chamel...@hdmi-hpd-fast.html Known issues Here are the changes found in Patchwork_14031 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-pci-d3-state: - fi-hsw-4770:[PASS][5] -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_busy@basic-flip-a: - fi-skl-iommu: [PASS][7] -> [SKIP][8] ([fdo#109271] / [fdo#109278]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-iommu/igt@kms_b...@basic-flip-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-iommu/igt@kms_b...@basic-flip-a.html - fi-skl-6260u: [PASS][9] -> [SKIP][10] ([fdo#109271] / [fdo#109278]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-6260u/igt@kms_b...@basic-flip-a.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-6260u/igt@kms_b...@basic-flip-a.html - fi-bdw-gvtdvm: [PASS][11] -> [SKIP][12] ([fdo#109271] / [fdo#109278]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-bdw-gvtdvm/igt@kms_b...@basic-flip-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-bdw-gvtdvm/igt@kms_b...@basic-flip-a.html * igt@kms_busy@basic-flip-b: - fi-bdw-5557u: [PASS][13] -> [SKIP][14] ([fdo#109271] / [fdo#109278]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-bdw-5557u/igt@kms_b...@basic-flip-b.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-bdw-5557u/igt@kms_b...@basic-flip-b.html - fi-skl-gvtdvm: [PASS][15] -> [SKIP][16] ([fdo#109271] / [fdo#109278]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-gvtdvm/igt@kms_b...@basic-flip-b.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-gvtdvm/igt@kms_b...@basic-flip-b.html - fi-cfl-guc: [PASS][17] -> [SKIP][18] ([fdo#109271] / [fdo#109278]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-cfl-guc/igt@kms_b...@basic-flip-b.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-cfl-guc/igt@kms_b...@basic-flip-b.html - fi-cfl-8700k: [PASS][19] -> [SKIP][20] ([fdo#109271] / [fdo#109278]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-cfl-8700k/igt@kms_b...@basic-flip-b.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-cfl-8700k/igt@kms_b...@basic-flip-b.html * igt@kms_chamelium@hdmi-crc-fast: - fi-skl-6700k2: [PASS][21] -> [FAIL][22] ([fdo#90]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-6700k2/igt@kms_chamel...@hdmi-crc-fast.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14031/fi-skl-6700k2/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size: - fi-skl-iommu: [PASS][23] -> [SKIP][24] ([fdo#109271]) +23 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-iommu/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-siz
[Intel-gfx] [PATCH 4/5] drm/i915/wopcm: Update error messages
All WOPCM error messages are device specific, so use
device specific error functions.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_wopcm.c | 44 --
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index ea02efb653a7..3b14dd5562ff 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -101,7 +101,8 @@ static inline u32 context_reserved_size(struct
drm_i915_private *i915)
return 0;
}
-static inline int gen9_check_dword_gap(u32 guc_wopcm_base, u32 guc_wopcm_size)
+static inline bool gen9_check_dword_gap(struct drm_i915_private *i915,
+ u32 guc_wopcm_base, u32 guc_wopcm_size)
{
u32 offset;
@@ -113,16 +114,18 @@ static inline int gen9_check_dword_gap(u32
guc_wopcm_base, u32 guc_wopcm_size)
offset = guc_wopcm_base + GEN9_GUC_WOPCM_OFFSET;
if (offset > guc_wopcm_size ||
(guc_wopcm_size - offset) < sizeof(u32)) {
- DRM_ERROR("GuC WOPCM size %uKiB is too small. %uKiB needed.\n",
- guc_wopcm_size / 1024,
- (u32)(offset + sizeof(u32)) / 1024);
- return -E2BIG;
+ dev_err(i915->drm.dev,
+ "WOPCM: invalid GuC region size: %uK < %uK\n",
+ guc_wopcm_size / SZ_1K,
+ (u32)(offset + sizeof(u32)) / SZ_1K);
+ return false;
}
- return 0;
+ return true;
}
-static inline int gen9_check_huc_fw_fits(u32 guc_wopcm_size, u32 huc_fw_size)
+static inline bool gen9_check_huc_fw_fits(struct drm_i915_private *i915,
+ u32 guc_wopcm_size, u32 huc_fw_size)
{
/*
* On Gen9 & CNL A0, hardware requires the total available GuC WOPCM
@@ -130,29 +133,30 @@ static inline int gen9_check_huc_fw_fits(u32
guc_wopcm_size, u32 huc_fw_size)
* firmware uploading would fail.
*/
if (huc_fw_size > guc_wopcm_size - GUC_WOPCM_RESERVED) {
- DRM_ERROR("HuC FW (%uKiB) won't fit in GuC WOPCM (%uKiB).\n",
- huc_fw_size / 1024,
- (guc_wopcm_size - GUC_WOPCM_RESERVED) / 1024);
- return -E2BIG;
+ dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+ intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
+ (guc_wopcm_size - GUC_WOPCM_RESERVED) / SZ_1K,
+ huc_fw_size / 1024);
+ return false;
}
- return 0;
+ return true;
}
static inline bool check_hw_restrictions(struct drm_i915_private *i915,
u32 guc_wopcm_base, u32 guc_wopcm_size,
u32 huc_fw_size)
{
- int err = 0;
-
- if (IS_GEN(i915, 9))
- err = gen9_check_dword_gap(guc_wopcm_base, guc_wopcm_size);
+ if (IS_GEN(i915, 9) && !gen9_check_dword_gap(i915, guc_wopcm_base,
+guc_wopcm_size))
+ return false;
- if (!err &&
- (IS_GEN(i915, 9) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)))
- err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
+ if ((IS_GEN(i915, 9) ||
+IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)) &&
+ !gen9_check_huc_fw_fits(i915, guc_wopcm_size, huc_fw_size))
+ return false;
- return !err;
+ return true;
}
static inline bool __check_layout(struct drm_i915_private *i915, u32
wopcm_size,
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915/wopcm: Try to use already locked WOPCM layout
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a fit.
This should enable us to reload driver with slightly different
HuC firmware (or even without HuC) without need to reboot.
v2: reordered/rebased
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Cc: Michal Winiarski
---
drivers/gpu/drm/i915/intel_wopcm.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 3ac05055bb08..ea02efb653a7 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -212,6 +212,21 @@ static inline bool __check_layout(struct drm_i915_private
*i915, u32 wopcm_size,
huc_fw_size);
}
+static bool __wopcm_regs_locked(struct intel_uncore *uncore,
+ u32 *guc_wopcm_base, u32 *guc_wopcm_size)
+{
+ u32 reg_base = intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET);
+ u32 reg_size = intel_uncore_read(uncore, GUC_WOPCM_SIZE);
+
+ if (!(reg_size & GUC_WOPCM_SIZE_LOCKED) ||
+ !(reg_base & GUC_WOPCM_OFFSET_VALID))
+ return false;
+
+ *guc_wopcm_base = reg_base & GUC_WOPCM_OFFSET_MASK;
+ *guc_wopcm_size = reg_size & GUC_WOPCM_SIZE_MASK;
+ return true;
+}
+
/**
* intel_wopcm_init() - Initialize the WOPCM structure.
* @wopcm: pointer to intel_wopcm.
@@ -225,8 +240,9 @@ static inline bool __check_layout(struct drm_i915_private
*i915, u32 wopcm_size,
void intel_wopcm_init(struct intel_wopcm *wopcm)
{
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
- u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->gt.uc.guc.fw);
- u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->gt.uc.huc.fw);
+ struct intel_gt *gt = &i915->gt;
+ u32 guc_fw_size = intel_uc_fw_get_upload_size(>->uc.guc.fw);
+ u32 huc_fw_size = intel_uc_fw_get_upload_size(>->uc.huc.fw);
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
@@ -244,6 +260,14 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
if (i915_inject_probe_failure(i915))
return;
+ if (__wopcm_regs_locked(gt->uncore, &guc_wopcm_base, &guc_wopcm_size)) {
+ DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
+"GuC WOPCM is already locked [%uK, %uK)\n",
+guc_wopcm_base / SZ_1K,
+guc_wopcm_size / SZ_1K);
+ goto check;
+ }
+
guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
GUC_WOPCM_OFFSET_ALIGNMENT);
guc_wopcm_base = max(wopcm->size - ctx_rsvd, guc_wopcm_base);
@@ -254,6 +278,7 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
"Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
guc_wopcm_base / SZ_1K, guc_wopcm_size / SZ_1K);
+check:
if (__check_layout(i915, wopcm->size, guc_wopcm_base, guc_wopcm_size,
guc_fw_size, huc_fw_size)) {
wopcm->guc.base = guc_wopcm_base;
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915/wopcm: Check WOPCM layout separately from calculations
We can do WOPCM partitioning using rough estimates and limits
and perform detailed check as separate step.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_wopcm.c | 105 -
1 file changed, 74 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 2975e00f57f5..3ac05055bb08 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -87,7 +87,8 @@ void intel_wopcm_init_early(struct intel_wopcm *wopcm)
else
wopcm->size = GEN9_WOPCM_SIZE;
- DRM_DEBUG_DRIVER("WOPCM size: %uKiB\n", wopcm->size / 1024);
+ DRM_DEV_DEBUG_DRIVER(i915->drm.dev, "WOPCM: size %uKiB\n",
+wopcm->size / SZ_1K);
}
static inline u32 context_reserved_size(struct drm_i915_private *i915)
@@ -138,9 +139,9 @@ static inline int gen9_check_huc_fw_fits(u32
guc_wopcm_size, u32 huc_fw_size)
return 0;
}
-static inline int check_hw_restriction(struct drm_i915_private *i915,
- u32 guc_wopcm_base, u32 guc_wopcm_size,
- u32 huc_fw_size)
+static inline bool check_hw_restrictions(struct drm_i915_private *i915,
+u32 guc_wopcm_base, u32 guc_wopcm_size,
+u32 huc_fw_size)
{
int err = 0;
@@ -151,7 +152,64 @@ static inline int check_hw_restriction(struct
drm_i915_private *i915,
(IS_GEN(i915, 9) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0)))
err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
- return err;
+ return !err;
+}
+
+static inline bool __check_layout(struct drm_i915_private *i915, u32
wopcm_size,
+ u32 guc_wopcm_base, u32 guc_wopcm_size,
+ u32 guc_fw_size, u32 huc_fw_size)
+{
+ const u32 ctx_rsvd = context_reserved_size(i915);
+ u32 size;
+
+ if (unlikely(guc_wopcm_base > wopcm_size)) {
+ dev_err(i915->drm.dev,
+ "WOPCM: invalid GuC region base: %uK > %uK\n",
+ guc_wopcm_base / SZ_1K, wopcm_size / SZ_1K);
+ return false;
+ }
+
+ size = wopcm_size - ctx_rsvd;
+ if (unlikely(guc_wopcm_base > size)) {
+ dev_err(i915->drm.dev,
+ "WOPCM: invalid GuC region base: %uK > %uK\n",
+ guc_wopcm_base / SZ_1K, size / SZ_1K);
+ return false;
+ }
+
+ if (unlikely(guc_wopcm_size > wopcm_size)) {
+ dev_err(i915->drm.dev,
+ "WOPCM: invalid GuC region size: %uK > %uK\n",
+ guc_wopcm_size / SZ_1K, wopcm_size / SZ_1K);
+ return false;
+ }
+
+ size = wopcm_size - guc_wopcm_base - ctx_rsvd;
+ if (unlikely(guc_wopcm_size > size)) {
+ dev_err(i915->drm.dev,
+ "WOPCM: invalid GuC region size: %uK > %uK\n",
+ guc_wopcm_size / SZ_1K, size / SZ_1K);
+ return false;
+ }
+
+ size = guc_fw_size + GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
+ if (unlikely(guc_wopcm_size < size)) {
+ dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+ intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_GUC),
+ guc_wopcm_size / SZ_1K, size / SZ_1K);
+ return false;
+ }
+
+ size = huc_fw_size + WOPCM_RESERVED_SIZE;
+ if (unlikely(guc_wopcm_base < size)) {
+ dev_err(i915->drm.dev, "WOPCM: no space for %s: %uK < %uK\n",
+ intel_uc_fw_type_repr(INTEL_UC_FW_TYPE_HUC),
+ guc_wopcm_base / SZ_1K, size / SZ_1K);
+ return false;
+ }
+
+ return check_hw_restrictions(i915, guc_wopcm_base, guc_wopcm_size,
+huc_fw_size);
}
/**
@@ -172,8 +230,6 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
- u32 guc_wopcm_rsvd;
- int err;
if (!guc_fw_size)
return;
@@ -183,39 +239,26 @@ void intel_wopcm_init(struct intel_wopcm *wopcm)
GEM_BUG_ON(wopcm->guc.size);
GEM_BUG_ON(guc_fw_size >= wopcm->size);
GEM_BUG_ON(huc_fw_size >= wopcm->size);
+ GEM_BUG_ON(ctx_rsvd + WOPCM_RESERVED_SIZE >= wopcm->size);
if (i915_inject_probe_failure(i915))
return;
guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
GUC_WOPCM_OFFSET_ALIGNMENT);
- if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
- DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
-
[Intel-gfx] [PATCH v2] drm/i915/uc: Fini hw even if GuC is not running
We should not be skipping uc_fini_hw on finding GuC
is no longer running. There is plenty of hw and internal
state that can be cleaned up without having to communicate
with GuC.
v2: better to check if fw is available (Michal)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110943
Signed-off-by: Fernando Pacheco
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 0dc2b0cf4604..67dec7dcc26f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -521,7 +521,7 @@ void intel_uc_fini_hw(struct intel_uc *uc)
{
struct intel_guc *guc = &uc->guc;
- if (!intel_guc_is_running(guc))
+ if (!intel_uc_fw_is_available(&guc->fw))
return;
if (intel_uc_supports_guc_submission(uc))
--
2.22.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu, Aug 15, 2019 at 7:16 PM Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 12:32:38PM -0400, Jerome Glisse wrote: > > On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote: > > > > > > > You have to wait for the gpu to finnish current processing in > > > > invalidate_range_start. Otherwise there's no point to any of this > > > > really. So the wait_event/dma_fence_wait are unavoidable really. > > > > > > I don't envy your task :| > > > > > > But, what you describe sure sounds like a 'registration cache' model, > > > not the 'shadow pte' model of coherency. > > > > > > The key difference is that a regirstationcache is allowed to become > > > incoherent with the VMA's because it holds page pins. It is a > > > programming bug in userspace to change VA mappings via mmap/munmap/etc > > > while the device is working on that VA, but it does not harm system > > > integrity because of the page pin. > > > > > > The cache ensures that each initiated operation sees a DMA setup that > > > matches the current VA map when the operation is initiated and allows > > > expensive device DMA setups to be re-used. > > > > > > A 'shadow pte' model (ie hmm) *really* needs device support to > > > directly block DMA access - ie trigger 'device page fault'. ie the > > > invalidate_start should inform the device to enter a fault mode and > > > that is it. If the device can't do that, then the driver probably > > > shouldn't persue this level of coherency. The driver would quickly get > > > into the messy locking problems like dma_fence_wait from a notifier. > > > > I think here we do not agree on the hardware requirement. For GPU > > we will always need to be able to wait for some GPU fence from inside > > the notifier callback, there is just no way around that for many of > > the GPUs today (i do not see any indication of that changing). > > I didn't say you couldn't wait, I was trying to say that the wait > should only be contigent on the HW itself. Ie you can wait on a GPU > page table lock, and you can wait on a GPU page table flush completion > via IRQ. > > What is troubling is to wait till some other thread gets a GPU command > completion and decr's a kref on the DMA buffer - which kinda looks > like what this dma_fence() stuff is all about. A driver like that > would have to be super careful to ensure consistent forward progress > toward dma ref == 0 when the system is under reclaim. > > ie by running it's entire IRQ flow under fs_reclaim locking. This is correct. At least for i915 it's already a required due to our shrinker also having to do the same. I think amdgpu isn't bothering with that since they have vram for most of the stuff, and just limit system memory usage to half of all and forgo the shrinker. Probably not the nicest approach. Anyway, both do the same mmu_notifier dance, just want to explain that we've been living with this for longer already. So yeah writing a gpu driver is not easy. > > associated with the mm_struct. In all GPU driver so far it is a short > > lived lock and nothing blocking is done while holding it (it is just > > about updating page table directory really wether it is filling it or > > clearing it). > > The main blocking I expect in a shadow PTE flow is waiting for the HW > to complete invalidations of its PTE cache. > > > > It is important to identify what model you are going for as defining a > > > 'registration cache' coherence expectation allows the driver to skip > > > blocking in invalidate_range_start. All it does is invalidate the > > > cache so that future operations pick up the new VA mapping. > > > > > > Intel's HFI RDMA driver uses this model extensively, and I think it is > > > well proven, within some limitations of course. > > > > > > At least, 'registration cache' is the only use model I know of where > > > it is acceptable to skip invalidate_range_end. > > > > Here GPU are not in the registration cache model, i know it might looks > > like it because of GUP but GUP was use just because hmm did not exist > > at the time. > > It is not because of GUP, it is because of the lack of > invalidate_range_end. A driver cannot correctly implement the SPTE > model without invalidate_range_end, even if it holds the page pins via > GUP. > > So, I've been assuming the few drivers without invalidate_range_end > are trying to do registration caching, rather than assuming they are > broken. I915 might just be broken. amdgpu does the full thing, using hmm_mirror. But still with dma_fence_wait. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu, Aug 15, 2019 at 07:21:47PM +0200, Daniel Vetter wrote: > On Thu, Aug 15, 2019 at 7:16 PM Jason Gunthorpe wrote: > > > > On Thu, Aug 15, 2019 at 12:32:38PM -0400, Jerome Glisse wrote: > > > On Thu, Aug 15, 2019 at 12:10:28PM -0300, Jason Gunthorpe wrote: > > > > On Thu, Aug 15, 2019 at 04:43:38PM +0200, Daniel Vetter wrote: > > > > > > > > > You have to wait for the gpu to finnish current processing in > > > > > invalidate_range_start. Otherwise there's no point to any of this > > > > > really. So the wait_event/dma_fence_wait are unavoidable really. > > > > > > > > I don't envy your task :| > > > > > > > > But, what you describe sure sounds like a 'registration cache' model, > > > > not the 'shadow pte' model of coherency. > > > > > > > > The key difference is that a regirstationcache is allowed to become > > > > incoherent with the VMA's because it holds page pins. It is a > > > > programming bug in userspace to change VA mappings via mmap/munmap/etc > > > > while the device is working on that VA, but it does not harm system > > > > integrity because of the page pin. > > > > > > > > The cache ensures that each initiated operation sees a DMA setup that > > > > matches the current VA map when the operation is initiated and allows > > > > expensive device DMA setups to be re-used. > > > > > > > > A 'shadow pte' model (ie hmm) *really* needs device support to > > > > directly block DMA access - ie trigger 'device page fault'. ie the > > > > invalidate_start should inform the device to enter a fault mode and > > > > that is it. If the device can't do that, then the driver probably > > > > shouldn't persue this level of coherency. The driver would quickly get > > > > into the messy locking problems like dma_fence_wait from a notifier. > > > > > > I think here we do not agree on the hardware requirement. For GPU > > > we will always need to be able to wait for some GPU fence from inside > > > the notifier callback, there is just no way around that for many of > > > the GPUs today (i do not see any indication of that changing). > > > > I didn't say you couldn't wait, I was trying to say that the wait > > should only be contigent on the HW itself. Ie you can wait on a GPU > > page table lock, and you can wait on a GPU page table flush completion > > via IRQ. > > > > What is troubling is to wait till some other thread gets a GPU command > > completion and decr's a kref on the DMA buffer - which kinda looks > > like what this dma_fence() stuff is all about. A driver like that > > would have to be super careful to ensure consistent forward progress > > toward dma ref == 0 when the system is under reclaim. > > > > ie by running it's entire IRQ flow under fs_reclaim locking. > > This is correct. At least for i915 it's already a required due to our > shrinker also having to do the same. I think amdgpu isn't bothering > with that since they have vram for most of the stuff, and just limit > system memory usage to half of all and forgo the shrinker. Probably > not the nicest approach. Anyway, both do the same mmu_notifier dance, > just want to explain that we've been living with this for longer > already. > > So yeah writing a gpu driver is not easy. > > > > associated with the mm_struct. In all GPU driver so far it is a short > > > lived lock and nothing blocking is done while holding it (it is just > > > about updating page table directory really wether it is filling it or > > > clearing it). > > > > The main blocking I expect in a shadow PTE flow is waiting for the HW > > to complete invalidations of its PTE cache. > > > > > > It is important to identify what model you are going for as defining a > > > > 'registration cache' coherence expectation allows the driver to skip > > > > blocking in invalidate_range_start. All it does is invalidate the > > > > cache so that future operations pick up the new VA mapping. > > > > > > > > Intel's HFI RDMA driver uses this model extensively, and I think it is > > > > well proven, within some limitations of course. > > > > > > > > At least, 'registration cache' is the only use model I know of where > > > > it is acceptable to skip invalidate_range_end. > > > > > > Here GPU are not in the registration cache model, i know it might looks > > > like it because of GUP but GUP was use just because hmm did not exist > > > at the time. > > > > It is not because of GUP, it is because of the lack of > > invalidate_range_end. A driver cannot correctly implement the SPTE > > model without invalidate_range_end, even if it holds the page pins via > > GUP. > > > > So, I've been assuming the few drivers without invalidate_range_end > > are trying to do registration caching, rather than assuming they are > > broken. > > I915 might just be broken. amdgpu does the full thing, using > hmm_mirror. But still with dma_fence_wait. Yeah i915 is broken but it never hurted anyone ;) I posted patch a long time ago to convert it to hmm but i delayed that to until i can get through making something
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu, Aug 15, 2019 at 02:35:57PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 06:25:16PM +0200, Daniel Vetter wrote: > > > I'm not really well versed in the details of our userptr, but both > > amdgpu and i915 wait for the gpu to complete from > > invalidate_range_start. Jerome has at least looked a lot at the amdgpu > > one, so maybe he can explain what exactly it is we're doing ... > > amdgpu is (wrongly) using hmm for something, I can't really tell what > it is trying to do. The calls to dma_fence under the > invalidate_range_start do not give me a good feeling. > > However, i915 shows all the signs of trying to follow the registration > cache model, it even has a nice comment in > i915_gem_userptr_get_pages() explaining that the races it has don't > matter because it is a user space bug to change the VA mapping in the > first place. That just screams registration cache to me. > > So it is fine to run HW that way, but if you do, there is no reason to > fence inside the invalidate_range end. Just orphan the DMA buffer and > clean it up & release the page pins when all DMA buffer refs go to > zero. The next access to that VA should get a new DMA buffer with the > right mapping. > > In other words the invalidation should be very simple without > complicated locking, or wait_event's. Look at hfi1 for example. This would break the today usage model of uptr and it will break userspace expectation ie if GPU is writting to that memory and that memory then the userspace want to make sure that it will see what the GPU write. Yes i915 is broken in respect to not having a end notifier and tracking active invalidation for a range but the GUP side of thing kind of hide this bug and it shrinks the window for bad to happen to something so small that i doubt anyone could ever hit it (still a bug thought). Cheers, Jérôme ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 22/22] drm/i915/mst: Do not hardcoded the crtcs that encoder can connect
On Thu, Jul 18, 2019 at 04:10:13PM +0300, Ville Syrjälä wrote: > On Fri, Jul 12, 2019 at 06:09:40PM -0700, Lucas De Marchi wrote: > > From: José Roberto de Souza > > > > Tiger Lake has up to 4 pipes so the mask would need to be 0xf instead of > > 0x7. Do not hardcode the mask so it allows the fake MST encoders to > > connect to all pipes no matter how many the platform has. > > > > Iterating over all pipes to keep consistent with intel_ddi_init(). > > > > Cc: Lucas De Marchi > > Cc: Ville Syrjälä > > Signed-off-by: José Roberto de Souza > > Signed-off-by: Lucas De Marchi > > --- > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c > > index 60652ebbdf61..1b79b6befa92 100644 > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c > > @@ -586,6 +586,8 @@ intel_dp_create_fake_mst_encoder(struct > > intel_digital_port *intel_dig_port, enum > > struct intel_dp_mst_encoder *intel_mst; > > struct intel_encoder *intel_encoder; > > struct drm_device *dev = intel_dig_port->base.base.dev; > > + struct drm_i915_private *dev_priv = to_i915(dev); > > + enum pipe pipe_iter; > > > > intel_mst = kzalloc(sizeof(*intel_mst), GFP_KERNEL); > > > > @@ -602,8 +604,9 @@ intel_dp_create_fake_mst_encoder(struct > > intel_digital_port *intel_dig_port, enum > > intel_encoder->type = INTEL_OUTPUT_DP_MST; > > intel_encoder->power_domain = intel_dig_port->base.power_domain; > > intel_encoder->port = intel_dig_port->base.port; > > - intel_encoder->crtc_mask = 0x7; > > intel_encoder->cloneable = 0; > > + for_each_pipe(dev_priv, pipe_iter) > > + intel_encoder->crtc_mask |= BIT(pipe_iter); > > https://patchwork.freedesktop.org/patch/316555/?series=63399&rev=1 Would it make sense to bring this patch in for now for TGL MST, until that larger series can land? -James > > > > > intel_encoder->compute_config = intel_dp_mst_compute_config; > > intel_encoder->disable = intel_mst_disable_dp; > > -- > > 2.21.0 > > -- > Ville Syrjälä > Intel > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and > > > __GFP_DIRECT_RECLAIM.. > > > > > > This matches the existing test in __need_fs_reclaim() - so if you are > > > OK with GFP_NOFS, aka __GFP_IO which triggers try_to_compact_pages(), > > > allocations during OOM, then I think fs_reclaim already matches what > > > you described? > > > > No GFP_NOFS is equally bad. Please read my other email explaining what > > the oom_reaper actually requires. In short no blocking on direct or > > indirect dependecy on memory allocation that might sleep. > > It is much easier to follow with some hints on code, so the true > requirement is that the OOM repear not block on GFP_FS and GFP_IO > allocations, great, that constraint is now clear. I still do not get why do you put FS/IO into the picture. This is really about __GFP_DIRECT_RECLAIM. > > > If you can express that in the existing lockdep machinery. All > > fine. But then consider deployments where lockdep is no-no because > > of the overhead. > > This is all for driver debugging. The point of lockdep is to find all > these paths without have to hit them as actual races, using debug > kernels. > > I don't think we need this kind of debugging on production kernels? Again, the primary motivation was a simple debugging aid that could be used without worrying about overhead. So lockdep is very often out of the question. > > > The best we got was drivers tested the VA range and returned success > > > if they had no interest. Which is a big win to be sure, but it looks > > > like getting any more is not really posssible. > > > > And that is already a great win! Because many notifiers only do care > > about particular mappings. Please note that backing off unconditioanlly > > will simply cause that the oom reaper will have to back off not doing > > any tear down anything. > > Well, I'm working to propose that we do the VA range test under core > mmu notifier code that cannot block and then we simply remove the idea > of blockable from drivers using this new 'range notifier'. > > I think this pretty much solves the concern? Well, my idea was that a range check and early bail out was a first step and then each specific notifier would be able to do a more specific check. I was not able to do the second step because that requires a deep understanding of the respective subsystem. Really all I do care about is to reclaim as much memory from the oom_reaper context as possible. And that cannot really be an unbounded process. Quite contrary it should be as swift as possible. From my cursory look some notifiers are able to achieve their task without blocking or depending on memory just fine. So bailing out unconditionally on the range of interest would just put us back. > > > However, we could (probably even should) make the drivers fs_reclaim > > > safe. > > > > > > If that is enough to guarantee progress of OOM, then lets consider > > > something like using current_gfp_context() to force PF_MEMALLOC_NOFS > > > allocation behavior on the driver callback and lockdep to try and keep > > > pushing on the the debugging, and dropping !blocking. > > > > How are you going to enforce indirect dependency? E.g. a lock that is > > also used in other context which depend on sleepable memory allocation > > to move forward. > > You mean like this: > >CPU0 CPU1 > mutex_lock() > kmalloc(GFP_KERNEL) no I mean __GFP_DIRECT_RECLAIM here. > mutex_unlock() > fs_reclaim_acquire() > mutex_lock() <- illegal: lock dep assertion I cannot really comment on how that is achieveable by lockdep. I managed to forget details about FS/IO reclaim recursion tracking already and I do not have time to learn it again. It was quite a hack. Anyway, let me repeat that the primary motivation was a simple aid. Not something as poverful as lockdep. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for More WOPCM fixes
== Series Details ==
Series: More WOPCM fixes
URL : https://patchwork.freedesktop.org/series/65263/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14032
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14032 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14032, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14032:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-cfl-guc: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-cfl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-cfl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- fi-skl-guc: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- fi-apl-guc: [PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [SKIP][7] ([fdo#109271]) -> [FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
* igt@runner@aborted:
- fi-cfl-guc: [FAIL][9] ([fdo#110755]) -> [FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-cfl-guc/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-cfl-guc/igt@run...@aborted.html
- fi-apl-guc: [FAIL][11] ([fdo#110755]) -> [FAIL][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-apl-guc/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-apl-guc/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_busy@busy-all:
- {fi-icl-guc}: [PASS][13] -> [SKIP][14] +10 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-guc/igt@gem_b...@busy-all.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-icl-guc/igt@gem_b...@busy-all.html
* igt@gem_ctx_switch@rcs0:
- {fi-icl-guc}: [INCOMPLETE][15] ([fdo#107713]) -> [SKIP][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-icl-guc}: NOTRUN -> [FAIL][17]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-icl-guc/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic-flip-b:
- {fi-icl-guc}: NOTRUN -> [SKIP][18] +67 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-icl-guc/igt@kms_b...@basic-flip-b.html
* igt@kms_chamelium@hdmi-hpd-fast:
- {fi-icl-u4}:[FAIL][19] ([fdo#111045]) -> [FAIL][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
Known issues
Here are the changes found in Patchwork_14032 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-apl-guc: [PASS][21] -> [SKIP][22] ([fdo#109271]) +77 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_ctx_switch@rcs0:
- fi-skl-guc: [PASS][23] -> [SKIP][24] ([fdo#109271]) +77 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-skl-guc/igt@gem_ctx_swi...@rcs0.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14032/fi-skl-guc/igt@gem_ctx_swi...@rcs0.html
* igt@gem_exec_basic@ba
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu, Aug 15, 2019 at 07:42:07PM +0200, Michal Hocko wrote: > On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote: > > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote: > > > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and > > > > __GFP_DIRECT_RECLAIM.. > > > > > > > > This matches the existing test in __need_fs_reclaim() - so if you are > > > > OK with GFP_NOFS, aka __GFP_IO which triggers try_to_compact_pages(), > > > > allocations during OOM, then I think fs_reclaim already matches what > > > > you described? > > > > > > No GFP_NOFS is equally bad. Please read my other email explaining what > > > the oom_reaper actually requires. In short no blocking on direct or > > > indirect dependecy on memory allocation that might sleep. > > > > It is much easier to follow with some hints on code, so the true > > requirement is that the OOM repear not block on GFP_FS and GFP_IO > > allocations, great, that constraint is now clear. > > I still do not get why do you put FS/IO into the picture. This is really > about __GFP_DIRECT_RECLAIM. > > > > > > If you can express that in the existing lockdep machinery. All > > > fine. But then consider deployments where lockdep is no-no because > > > of the overhead. > > > > This is all for driver debugging. The point of lockdep is to find all > > these paths without have to hit them as actual races, using debug > > kernels. > > > > I don't think we need this kind of debugging on production kernels? > > Again, the primary motivation was a simple debugging aid that could be > used without worrying about overhead. So lockdep is very often out of > the question. > > > > > The best we got was drivers tested the VA range and returned success > > > > if they had no interest. Which is a big win to be sure, but it looks > > > > like getting any more is not really posssible. > > > > > > And that is already a great win! Because many notifiers only do care > > > about particular mappings. Please note that backing off unconditioanlly > > > will simply cause that the oom reaper will have to back off not doing > > > any tear down anything. > > > > Well, I'm working to propose that we do the VA range test under core > > mmu notifier code that cannot block and then we simply remove the idea > > of blockable from drivers using this new 'range notifier'. > > > > I think this pretty much solves the concern? > > Well, my idea was that a range check and early bail out was a first step > and then each specific notifier would be able to do a more specific > check. I was not able to do the second step because that requires a deep > understanding of the respective subsystem. > > Really all I do care about is to reclaim as much memory from the > oom_reaper context as possible. And that cannot really be an unbounded > process. Quite contrary it should be as swift as possible. From my > cursory look some notifiers are able to achieve their task without > blocking or depending on memory just fine. So bailing out > unconditionally on the range of interest would just put us back. Agree, OOM just asking the question: can i unmap that page quickly ? so that me (OOM) can swap it out. In many cases the driver need to lookup something to see if at the time the memory is just not in use and can be reclaim right away. So driver should have a path to optimistically update its state to allow quick reclaim. > > > > However, we could (probably even should) make the drivers fs_reclaim > > > > safe. > > > > > > > > If that is enough to guarantee progress of OOM, then lets consider > > > > something like using current_gfp_context() to force PF_MEMALLOC_NOFS > > > > allocation behavior on the driver callback and lockdep to try and keep > > > > pushing on the the debugging, and dropping !blocking. > > > > > > How are you going to enforce indirect dependency? E.g. a lock that is > > > also used in other context which depend on sleepable memory allocation > > > to move forward. > > > > You mean like this: > > > >CPU0 CPU1 > > mutex_lock() > > kmalloc(GFP_KERNEL) > > no I mean __GFP_DIRECT_RECLAIM here. > > > mutex_unlock() > > fs_reclaim_acquire() > > mutex_lock() <- illegal: lock dep assertion > > I cannot really comment on how that is achieveable by lockdep. I managed > to forget details about FS/IO reclaim recursion tracking already and I > do not have time to learn it again. It was quite a hack. Anyway, let me > repeat that the primary motivation was a simple aid. Not something as > poverful as lockdep. I feel that the fs_reclaim_acquire() is just too heavy weight here. I do think that Daniel patches improve the debugging situation without burdening anything so i am in favor or merging that. I do not think we should devote too much time into fs_reclaim(), our time would be better spend in improving the
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Enabling DSC on Pipe A for TGL
== Series Details == Series: drm/i915/tgl: Enabling DSC on Pipe A for TGL URL : https://patchwork.freedesktop.org/series/65216/ State : success == Summary == CI Bug Log - changes from CI_DRM_6710_full -> Patchwork_14019_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14019_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-apl5/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-apl7/igt@gem_...@in-flight-suspend.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@gem_exec_balan...@smoke.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb3/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb7/igt@gem_exec_sched...@preempt-other-chain-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@i915_suspend@sysfs-reader: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-skl6/igt@i915_susp...@sysfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-skl6/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_legacy@cursor-vs-flip-atomic: - shard-hsw: [PASS][9] -> [FAIL][10] ([fdo#103355]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-hsw4/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-kbl: [PASS][11] -> [INCOMPLETE][12] ([fdo#103665]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-kbl3/igt@kms_f...@flip-vs-suspend-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-kbl6/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103166]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-y.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb5/igt@kms_psr@psr2_cursor_render.html * igt@prime_vgem@fence-wait-bsd2: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109276]) +19 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@prime_v...@fence-wait-bsd2.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-iclb5/igt@prime_v...@fence-wait-bsd2.html * igt@sw_sync@sync_multi_consumer: - shard-apl: [PASS][23] -> [INCOMPLETE][24] ([fdo#103927]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-apl3/igt@sw_sync@sync_multi_consumer.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14019/shard-apl5/igt@sw_sync@sync_multi_consumer.html Possible fixes * igt@gem_eio@reset-stress: - shard-snb: [FAIL][25] ([fdo#109661]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip
Re: [Intel-gfx] [PATCH v7 1/9] drm_dp_cec: add connector info support.
Reviewed-by: Lyude Paul
On Wed, 2019-08-14 at 12:44 +0200, Dariusz Marcinkiewicz wrote:
> Pass the connector info to the CEC adapter. This makes it possible
> to associate the CEC adapter with the corresponding drm connector.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkuil
> Tested-by: Hans Verkuil
> ---
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> drivers/gpu/drm/drm_dp_cec.c | 25 ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +--
> drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +--
> include/drm/drm_dp_helper.h | 17 ++---
> 5 files changed, 27 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 16218a202b591..5ec14efd4d8cb 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -416,7 +416,7 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
>
> drm_dp_aux_register(&aconnector->dm_dp_aux.aux);
> drm_dp_cec_register_connector(&aconnector->dm_dp_aux.aux,
> - aconnector->base.name, dm->adev->dev);
> + &aconnector->base);
> aconnector->mst_mgr.cbs = &dm_mst_cbs;
> drm_dp_mst_topology_mgr_init(
> &aconnector->mst_mgr,
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index b15cee85b702b..b457c16c3a8bb 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -8,7 +8,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
>
> /*
> @@ -295,7 +297,10 @@ static void drm_dp_cec_unregister_work(struct work_struct
> *work)
> */
> void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> {
> - u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD;
> + struct drm_connector *connector = aux->cec.connector;
> + u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> +CEC_CAP_CONNECTOR_INFO;
> + struct cec_connector_info conn_info;
> unsigned int num_las = 1;
> u8 cap;
>
> @@ -344,13 +349,17 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>
> /* Create a new adapter */
> aux->cec.adap = cec_allocate_adapter(&drm_dp_cec_adap_ops,
> - aux, aux->cec.name, cec_caps,
> + aux, connector->name, cec_caps,
>num_las);
> if (IS_ERR(aux->cec.adap)) {
> aux->cec.adap = NULL;
> goto unlock;
> }
> - if (cec_register_adapter(aux->cec.adap, aux->cec.parent)) {
> +
> + cec_fill_conn_info_from_drm(&conn_info, connector);
> + cec_s_conn_info(aux->cec.adap, &conn_info);
> +
> + if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
> cec_delete_adapter(aux->cec.adap);
> aux->cec.adap = NULL;
> } else {
> @@ -406,22 +415,20 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
> /**
> * drm_dp_cec_register_connector() - register a new connector
> * @aux: DisplayPort AUX channel
> - * @name: name of the CEC device
> - * @parent: parent device
> + * @connector: drm connector
> *
> * A new connector was registered with associated CEC adapter name and
> * CEC adapter parent device. After registering the name and parent
> * drm_dp_cec_set_edid() is called to check if the connector supports
> * CEC and to register a CEC adapter if that is the case.
> */
> -void drm_dp_cec_register_connector(struct drm_dp_aux *aux, const char *name,
> -struct device *parent)
> +void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> +struct drm_connector *connector)
> {
> WARN_ON(aux->cec.adap);
> if (WARN_ON(!aux->transfer))
> return;
> - aux->cec.name = name;
> - aux->cec.parent = parent;
> + aux->cec.connector = connector;
> INIT_DELAYED_WORK(&aux->cec.unregister_work,
> drm_dp_cec_unregister_work);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1092499115760..de2486fe7bf2d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5497,7 +5497,6 @@ static int
> intel_dp_connector_register(struct drm_connector *connector)
> {
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> - struct drm_device *dev = connector->dev;
> int ret;
>
> ret = intel_connector_register(connector);
> @@ -5512,8 +5511,7 @@ intel_dp_connector_register(struct drm_connector
> *connector)
> intel_dp
[Intel-gfx] [PATCH] Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"
In the recent snd merge of
ddf7cb83b0f4 ALSA: hda: Unexport a few more stuff
53eff75e5f4d ALSA: hda: Drop export of snd_hdac_bus_add/remove_device()
ee5f85d9290f ALSA: hda: Add codec on bus address table lately
f2dbe87c5ac1 ALSA: hda - Drop unsol event handler for Intel HDMI codecs
module unload dies on all a couple of machines with
<1> [281.912684] BUG: kernel NULL pointer dereference, address:
<1> [281.912697] #PF: supervisor read access in kernel mode
<1> [281.912703] #PF: error_code(0x) - not-present page
<6> [281.912709] PGD 0 P4D 0
<4> [281.912714] Oops: [#1] PREEMPT SMP PTI
<4> [281.912721] CPU: 3 PID: 2842 Comm: i915_module_loa Tainted: G U
5.3.0-rc4-CI-CI_DRM_6712+ #1
<4> [281.912730] Hardware name: Hewlett-Packard HP EliteBook 8440p/172A, BIOS
68CCU Ver. F.24 09/13/2013
<4> [281.912744] RIP: 0010:__list_del_entry_valid+0x25/0x90
<4> [281.912751] Code: c3 0f 1f 40 00 48 8b 07 48 b9 00 01 00 00 00 00 ad de 48
8b 57 08 48 39 c8 74 26 48 b9 22 01 00 00 00 00 ad de 48 39 ca 74 2e <48> 8b 32
48 39 fe 75 3a 48 8b 50 08 48 39 f2 75 48 b8 01 00 00 00
<4> [281.912767] RSP: 0018:c972bca8 EFLAGS: 00010217
<4> [281.912774] RAX: RBX: 88812f8933f8 RCX:
dead0122
<4> [281.912782] RDX: RSI: 88812f8933f8 RDI:
88812f8938a8
<4> [281.912789] RBP: 88812e7ce7e8 R08: R09:
<4> [281.912796] R10: R11: R12:
88812f8938a8
<4> [281.912803] R13: 88812c8722a8 R14: c972bf08 R15:
888129761df8
<4> [281.912811] FS: 7fb4913a9e40() GS:888133b8()
knlGS:
<4> [281.912819] CS: 0010 DS: ES: CR0: 80050033
<4> [281.912826] CR2: CR3: 00012867a000 CR4:
06e0
<4> [281.912833] Call Trace:
<4> [281.912844] snd_hdac_bus_remove_device+0x2e/0xb0 [snd_hda_core]
<4> [281.912854] snd_hdac_device_exit+0x31/0x60 [snd_hda_core]
<4> [281.912866] snd_hda_codec_dev_release+0x24/0x50 [snd_hda_codec]
<4> [281.912876] device_release+0x22/0x80
<4> [281.912883] kobject_put+0x86/0x1b0
<4> [281.912891] snd_hda_codec_dev_free+0x5c/0x60 [snd_hda_codec]
<4> [281.912899] __snd_device_free+0x4a/0x80
<4> [281.912904] snd_device_free_all+0x36/0x90
<4> [281.912911] release_card_device+0x14/0x60
<4> [281.912917] device_release+0x22/0x80
<4> [281.912923] kobject_put+0x86/0x1b0
<4> [281.912928] snd_card_free+0x60/0x90
<4> [281.912939] pci_device_remove+0x36/0xb0
<4> [281.912946] device_release_driver_internal+0xd3/0x1b0
<4> [281.912953] unbind_store+0xc3/0x120
<4> [281.912962] kernfs_fop_write+0x104/0x190
<4> [281.912971] vfs_write+0xbd/0x1d0
<4> [281.912977] ksys_write+0x8f/0xe0
<4> [281.912984] do_syscall_64+0x55/0x1c0
Cc: Takashi Iwai
---
sound/pci/hda/patch_hdmi.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 933c7bf47ef6..2096993eaf28 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2760,8 +2760,6 @@ static void i915_pin_cvt_fixup(struct hda_codec *codec,
/* precondition and allocation for Intel codecs */
static int alloc_intel_hdmi(struct hda_codec *codec)
{
- int err;
-
/* requires i915 binding */
if (!codec->bus->core.audio_component) {
codec_info(codec, "No i915 binding for Intel HDMI/DP codec\n");
@@ -2770,12 +2768,7 @@ static int alloc_intel_hdmi(struct hda_codec *codec)
return -ENODEV;
}
- err = alloc_generic_hdmi(codec);
- if (err < 0)
- return err;
- /* no need to handle unsol events */
- codec->patch_ops.unsol_event = NULL;
- return 0;
+ return alloc_generic_hdmi(codec);
}
/* parse and post-process for Intel codecs */
--
2.23.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Fini hw even if GuC is not running (rev2)
== Series Details ==
Series: drm/i915/uc: Fini hw even if GuC is not running (rev2)
URL : https://patchwork.freedesktop.org/series/65140/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14033
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14033/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14033:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_chamelium@hdmi-hpd-fast:
- {fi-icl-u4}:[FAIL][1] ([fdo#111045]) -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14033/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
Known issues
Here are the changes found in Patchwork_14033 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_ctx_switch@rcs0:
- {fi-icl-guc}: [INCOMPLETE][3] ([fdo#107713]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14033/fi-icl-guc/igt@gem_ctx_swi...@rcs0.html
* igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][5] ([fdo#111045]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14033/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
Participating hosts (53 -> 45)
--
Additional (1): fi-gdg-551
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-hsw-4770 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6712 -> Patchwork_14033
CI-20190529: 20190529
CI_DRM_6712: cd7b3a5a9d3b20684a62b8c1a33707c162ee3629 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14033: ad7f85475cb7265026b2a977b38edc2d07311e63 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ad7f85475cb7 drm/i915/uc: Fini hw even if GuC is not running
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14033/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL
On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha Tolakanahalli Pradeep
wrote:
> Removing restriction on Pipe A as TigerLake onwards, all the pipes support
> DSC.
May be elaborate this commit message a little bit something like:
"On previous platforms, DSC was not supported on Pipe A while starting TGL, its
is supported
on all pipes. So remove the DSC and FEC restriction on Pipe A for TGL onwards.
>
> Cc: Manasi Navare
> Signed-off-by: Madhumitha Tolakanahalli Pradeep
>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4884c87c8ed7..a5b50f93fac5 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1739,8 +1739,12 @@ static bool intel_dp_source_supports_fec(struct
> intel_dp *intel_dp,
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>
> - return INTEL_GEN(dev_priv) >= 11 &&
> - pipe_config->cpu_transcoder != TRANSCODER_A;
> + /* On TGL, DSC is supported on all Pipes */
FEC supported on all pipes
> + if (INTEL_GEN(dev_priv) >= 12)
> + return true;
> + else
> + return INTEL_GEN(dev_priv) == 11 &&
> + pipe_config->cpu_transcoder != TRANSCODER_A;
> }
>
> static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
> @@ -1755,8 +1759,12 @@ static bool intel_dp_source_supports_dsc(struct
> intel_dp *intel_dp,
> {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>
> - return INTEL_GEN(dev_priv) >= 10 &&
> - pipe_config->cpu_transcoder != TRANSCODER_A;
> + /* On TGL, DSC is supported on all Pipes */
> + if (INTEL_GEN(dev_priv) >= 12)
> + return true;
> + else
> + return (INTEL_GEN(dev_priv) == 10 || INTEL_GEN(dev_priv) == 11)
> &&
Why cant you just use INTEL_GEN(dev_priv) >=10 ?
Manasi
> + pipe_config->cpu_transcoder != TRANSCODER_A;
> }
>
> static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> --
> 2.17.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu, Aug 15, 2019 at 03:01:59PM -0300, Jason Gunthorpe wrote: > On Thu, Aug 15, 2019 at 01:39:22PM -0400, Jerome Glisse wrote: > > On Thu, Aug 15, 2019 at 02:35:57PM -0300, Jason Gunthorpe wrote: > > > On Thu, Aug 15, 2019 at 06:25:16PM +0200, Daniel Vetter wrote: > > > > > > > I'm not really well versed in the details of our userptr, but both > > > > amdgpu and i915 wait for the gpu to complete from > > > > invalidate_range_start. Jerome has at least looked a lot at the amdgpu > > > > one, so maybe he can explain what exactly it is we're doing ... > > > > > > amdgpu is (wrongly) using hmm for something, I can't really tell what > > > it is trying to do. The calls to dma_fence under the > > > invalidate_range_start do not give me a good feeling. > > > > > > However, i915 shows all the signs of trying to follow the registration > > > cache model, it even has a nice comment in > > > i915_gem_userptr_get_pages() explaining that the races it has don't > > > matter because it is a user space bug to change the VA mapping in the > > > first place. That just screams registration cache to me. > > > > > > So it is fine to run HW that way, but if you do, there is no reason to > > > fence inside the invalidate_range end. Just orphan the DMA buffer and > > > clean it up & release the page pins when all DMA buffer refs go to > > > zero. The next access to that VA should get a new DMA buffer with the > > > right mapping. > > > > > > In other words the invalidation should be very simple without > > > complicated locking, or wait_event's. Look at hfi1 for example. > > > > This would break the today usage model of uptr and it will > > break userspace expectation ie if GPU is writting to that > > memory and that memory then the userspace want to make sure > > that it will see what the GPU write. > > How exactly? This is holding the page pin, so the only way the VA > mapping can be changed is via explicit user action. > > ie: > >gpu_write_something(va, size) >mmap(.., va, size, MMAP_FIXED); >gpu_wait_done() > > This is racy and indeterminate with both models. > > Based on the comment in i915 it appears to be going on the model that > changes to the mmap by userspace when the GPU is working on it is a > programming bug. This is reasonable, lots of systems use this kind of > consistency model. Well userspace process doing munmap(), mremap(), fork() and things like that are a bug from the i915 kernel and userspace contract point of view. But things like migration or reclaim are not cover under that contract and for those the expectation is that CPU access to the same virtual address should allow to get what was last written to it either by the GPU or the CPU. > > Since the driver seems to rely on a dma_fence to block DMA access, it > looks to me like the kernel has full visibility to the > 'gpu_write_something()' and 'gpu_wait_done()' markers. So let's only consider the case where GPU wants to write to the memory (the read only case is obviously right and not need any notifier in fact) and like above the only thing we care about is reclaim or migration (for instance because of some numa compaction) as the rest is cover by i915 userspace contract. So in the write case we do GUPfast(write=true) which will be "safe" from any concurrent CPU page table update ie if GUPfast get a reference for the page then any racing CPU page table update will not be able to migrate or reclaim the page and thus the virtual address to page association will be preserve. This is only true because of GUPfast(), now if GUPfast() fails it will fallback to the slow GUP case which make the same thing safe by taking the page table lock. Because of the reference on the page the i915 driver can forego the mmu notifier end callback. The thing here is that taking a page reference is pointless if we have better synchronization and tracking of mmu notifier. Hence converting to hmm mirror allows to avoid taking a ref on the page while still keeping the same functionality as of today. > I think trying to use hmm_range_fault on HW that can't do HW page > faulting and HW 'TLB shootdown' is a very, very bad idea. I fear that > is what amd gpu is trying to do. > > I haven't yet seen anything that looks like 'TLB shootdown' in i915?? GPU driver have complex usage pattern the tlb shootdown is implicit once the GEM object associated with the uptr is invalidated it means next time userspace submit command against that GEM object it will have to re-validate it which means re-program the GPU page table to point to the proper address (and re-call GUP). So the whole GPU page table update is all hidden behind GEM function like i915_gem_object_unbind() (or ttm invalidate for amd/radeon). Technicaly those GPU do not support page faulting but because of the way GPU works you know that you have frequent checkpoint where you can unbind things. This is what is happening here. Also not all GPU engines can handle page fault, this is true of all GP
Re: [Intel-gfx] [PATCH 2/8] drm/i915/gt: Track timeline activeness in enter/exit
On Wed, 14 Aug 2019 at 10:44, Chris Wilson wrote: > > Lift moving the timeline to/from the active_list on enter/exit in order > to shorten the active tracking span in comparison to the existing > pin/unpin. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"
== Series Details ==
Series: Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"
URL : https://patchwork.freedesktop.org/series/65267/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d4ceec6bc210 Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ddf7cb83b0f4 ("ALSA: hda:
Unexport a few more stuff")'
#9:
ddf7cb83b0f4 ALSA: hda: Unexport a few more stuff
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 53eff75e5f4d ("ALSA: hda: Drop
export of snd_hdac_bus_add/remove_device()")'
#10:
53eff75e5f4d ALSA: hda: Drop export of snd_hdac_bus_add/remove_device()
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ee5f85d9290f ("ALSA: hda: Add
codec on bus address table lately")'
#11:
ee5f85d9290f ALSA: hda: Add codec on bus address table lately
-:12: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit f2dbe87c5ac1 ("ALSA: hda - Drop
unsol event handler for Intel HDMI codecs")'
#12:
f2dbe87c5ac1 ALSA: hda - Drop unsol event handler for Intel HDMI codecs
-:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#16:
<1> [281.912684] BUG: kernel NULL pointer dereference, address:
-:83: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 5 errors, 1 warnings, 0 checks, 21 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: disable DDIC
== Series Details == Series: drm/i915/tgl: disable DDIC URL : https://patchwork.freedesktop.org/series/65217/ State : success == Summary == CI Bug Log - changes from CI_DRM_6710_full -> Patchwork_14020_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14020_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb3/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@gem_exec_balan...@smoke.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb5/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb7/igt@gem_exec_sched...@preempt-other-chain-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-apl5/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#104108]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-skl4/igt@kms_fbcon_...@fbc-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-skl1/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_flip@2x-flip-vs-expired-vblank: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#102887]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-hsw5/igt@kms_f...@2x-flip-vs-expired-vblank.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-hsw2/igt@kms_f...@2x-flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb4/igt@kms_psr@psr2_cursor_render.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109276]) +15 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb4/igt@prime_b...@hang-bsd2.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb3/igt@prime_b...@hang-bsd2.html Possible fixes * igt@gem_eio@reset-stress: - shard-snb: [FAIL][21] ([fdo#109661]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-snb2/igt@gem_...@reset-stress.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-snb2/igt@gem_...@reset-stress.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [SKIP][23] ([fdo#111325]) -> [PASS][24] +4 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6710/shard-iclb2/igt@gem_exec_as...@concurrent-writes-bsd.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14020/shard-iclb6/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_exec_schedule@preempt-contexts-bsd2: - shard-iclb: [SKIP][25] ([fdo#109276]) -> [PASS][26] +16 similar is
Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked
Quoting Daniel Vetter (2019-08-14 18:20:53) > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote: > > Now that dma_fence_signal always takes the spinlock to flush the > > cb_list, simply take the spinlock and call dma_fence_signal_locked() to > > avoid code repetition. > > > > Suggested-by: Christian König > > Signed-off-by: Chris Wilson > > Cc: Christian König > > Hm, I think this largely defeats the point of having the lockless signal > enabling trickery in dma_fence. Maybe that part isn't needed by anyone, > but feels like a thing that needs a notch more thought. And if we need it, > maybe a bit more cleanup. You mean dma_fence_enable_sw_signaling(). The only user appears to be to flush fences, which is actually the intent of always notifying the signal cb. By always doing the callbacks, we can avoid installing the interrupt and completely saturating CPUs with irqs, instead doing a batch in a leisurely timer callback if not flushed naturally. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked
On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson wrote: > Quoting Daniel Vetter (2019-08-14 18:20:53) > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote: > > > Now that dma_fence_signal always takes the spinlock to flush the > > > cb_list, simply take the spinlock and call dma_fence_signal_locked() to > > > avoid code repetition. > > > > > > Suggested-by: Christian König > > > Signed-off-by: Chris Wilson > > > Cc: Christian König > > > > Hm, I think this largely defeats the point of having the lockless signal > > enabling trickery in dma_fence. Maybe that part isn't needed by anyone, > > but feels like a thing that needs a notch more thought. And if we need it, > > maybe a bit more cleanup. > > You mean dma_fence_enable_sw_signaling(). The only user appears to be to > flush fences, which is actually the intent of always notifying the signal > cb. By always doing the callbacks, we can avoid installing the interrupt > and completely saturating CPUs with irqs, instead doing a batch in a > leisurely timer callback if not flushed naturally. Yeah I'm not against ditching this, but can't we ditch a lot more if we just always take the spinlock in those paths now anyways? Kinda not worth having the complexity anymore. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL
On Thu, 2019-08-15 at 11:24 -0700, Manasi Navare wrote:
> On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha Tolakanahalli
> Pradeep wrote:
> > Removing restriction on Pipe A as TigerLake onwards, all the pipes
> > support DSC.
>
> May be elaborate this commit message a little bit something like:
> "On previous platforms, DSC was not supported on Pipe A while
> starting TGL, its is supported
> on all pipes. So remove the DSC and FEC restriction on Pipe A for TGL
> onwards.
>
Alright, will update that for rev2.
> >
> > Cc: Manasi Navare
> > Signed-off-by: Madhumitha Tolakanahalli Pradeep <
> > madhumitha.tolakanahalli.prad...@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 16
> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 4884c87c8ed7..a5b50f93fac5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1739,8 +1739,12 @@ static bool
> > intel_dp_source_supports_fec(struct intel_dp *intel_dp,
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> >
> > - return INTEL_GEN(dev_priv) >= 11 &&
> > - pipe_config->cpu_transcoder != TRANSCODER_A;
> > + /* On TGL, DSC is supported on all Pipes */
>
> FEC supported on all pipes
Oops, will change this.
> > + if (INTEL_GEN(dev_priv) >= 12)
> > + return true;
> > + else
> > + return INTEL_GEN(dev_priv) == 11 &&
> > + pipe_config->cpu_transcoder != TRANSCODER_A;
> > }
> >
> > static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
> > @@ -1755,8 +1759,12 @@ static bool
> > intel_dp_source_supports_dsc(struct intel_dp *intel_dp,
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> >
> > - return INTEL_GEN(dev_priv) >= 10 &&
> > - pipe_config->cpu_transcoder != TRANSCODER_A;
> > + /* On TGL, DSC is supported on all Pipes */
> > + if (INTEL_GEN(dev_priv) >= 12)
> > + return true;
> > + else
> > + return (INTEL_GEN(dev_priv) == 10 ||
> > INTEL_GEN(dev_priv) == 11) &&
>
> Why cant you just use INTEL_GEN(dev_priv) >=10 ?
INTEL_GEN(dev_priv) >= 10 was the existing condition. With the new
condition added, there would be an overlapping set
ie INTEL_GEN(dev_priv) >= 10 would still be TRUE for GEN >= 12. Though
this wouldn't affect the logic of the code, thought it would make more
sense to sperate it out this way.
>
> Manasi
>
> > + pipe_config->cpu_transcoder != TRANSCODER_A;
> > }
> >
> > static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> > --
> > 2.17.1
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL
On Thu, Aug 15, 2019 at 11:39:54AM -0700, Tolakanahalli Pradeep, Madhumitha
wrote:
> On Thu, 2019-08-15 at 11:24 -0700, Manasi Navare wrote:
> > On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha Tolakanahalli
> > Pradeep wrote:
> > > Removing restriction on Pipe A as TigerLake onwards, all the pipes
> > > support DSC.
> >
> > May be elaborate this commit message a little bit something like:
> > "On previous platforms, DSC was not supported on Pipe A while
> > starting TGL, its is supported
> > on all pipes. So remove the DSC and FEC restriction on Pipe A for TGL
> > onwards.
> >
>
> Alright, will update that for rev2.
>
> > >
> > > Cc: Manasi Navare
> > > Signed-off-by: Madhumitha Tolakanahalli Pradeep <
> > > madhumitha.tolakanahalli.prad...@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 16
> > > 1 file changed, 12 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 4884c87c8ed7..a5b50f93fac5 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -1739,8 +1739,12 @@ static bool
> > > intel_dp_source_supports_fec(struct intel_dp *intel_dp,
> > > {
> > > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > >
> > > - return INTEL_GEN(dev_priv) >= 11 &&
> > > - pipe_config->cpu_transcoder != TRANSCODER_A;
> > > + /* On TGL, DSC is supported on all Pipes */
> >
> > FEC supported on all pipes
>
> Oops, will change this.
>
> > > + if (INTEL_GEN(dev_priv) >= 12)
> > > + return true;
> > > + else
> > > + return INTEL_GEN(dev_priv) == 11 &&
Also here I think its better to use IS_GEN(dev_priv, 11)
> > > + pipe_config->cpu_transcoder != TRANSCODER_A;
> > > }
> > >
> > > static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
> > > @@ -1755,8 +1759,12 @@ static bool
> > > intel_dp_source_supports_dsc(struct intel_dp *intel_dp,
> > > {
> > > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > >
> > > - return INTEL_GEN(dev_priv) >= 10 &&
> > > - pipe_config->cpu_transcoder != TRANSCODER_A;
> > > + /* On TGL, DSC is supported on all Pipes */
> > > + if (INTEL_GEN(dev_priv) >= 12)
> > > + return true;
> > > + else
> > > + return (INTEL_GEN(dev_priv) == 10 ||
> > > INTEL_GEN(dev_priv) == 11) &&
> >
> > Why cant you just use INTEL_GEN(dev_priv) >=10 ?
>
> INTEL_GEN(dev_priv) >= 10 was the existing condition. With the new
> condition added, there would be an overlapping set
> ie INTEL_GEN(dev_priv) >= 10 would still be TRUE for GEN >= 12. Though
> this wouldn't affect the logic of the code, thought it would make more
> sense to sperate it out this way.
But since we return for GEN >=12 , the only time it would fall to GEN >=10 is
for 10 and 11
so that should work, or you could use IS_GEN(dev_priv, 10) || IS_GEN(dev_priv,
11)
But may be check with Lucas on what would be the preferred way
Manasi
>
> >
> > Manasi
> >
> > > + pipe_config->cpu_transcoder != TRANSCODER_A;
> > > }
> > >
> > > static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> > > --
> > > 2.17.1
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915/gt: Convert timeline tracking to spinlock
On Wed, 14 Aug 2019 at 10:27, Chris Wilson wrote: > > Convert the list manipulation of active to use spinlocks so that we can active_list > perform the updates from underneath a quick interrupt callback. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/4] dma-fence: Have dma_fence_signal call signal_locked
Quoting Daniel Vetter (2019-08-15 19:48:42)
> On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-08-14 18:20:53)
> > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> > > > Now that dma_fence_signal always takes the spinlock to flush the
> > > > cb_list, simply take the spinlock and call dma_fence_signal_locked() to
> > > > avoid code repetition.
> > > >
> > > > Suggested-by: Christian König
> > > > Signed-off-by: Chris Wilson
> > > > Cc: Christian König
> > >
> > > Hm, I think this largely defeats the point of having the lockless signal
> > > enabling trickery in dma_fence. Maybe that part isn't needed by anyone,
> > > but feels like a thing that needs a notch more thought. And if we need it,
> > > maybe a bit more cleanup.
> >
> > You mean dma_fence_enable_sw_signaling(). The only user appears to be to
> > flush fences, which is actually the intent of always notifying the signal
> > cb. By always doing the callbacks, we can avoid installing the interrupt
> > and completely saturating CPUs with irqs, instead doing a batch in a
> > leisurely timer callback if not flushed naturally.
>
> Yeah I'm not against ditching this,
I was just thinking aloud working out what the current use case in ttm
was for.
> but can't we ditch a lot more if
> we just always take the spinlock in those paths now anyways? Kinda not
> worth having the complexity anymore.
You would be able to drop the was_set from dma_fence_add_callback. Say
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 59ac96ec7ba8..e566445134a2 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -345,38 +345,31 @@ int dma_fence_add_callback(struct dma_fence *fence,
struct dma_fence_cb *cb,
dma_fence_func_t func)
{
unsigned long flags;
- int ret = 0;
- bool was_set;
+ int ret = -ENOENT;
if (WARN_ON(!fence || !func))
return -EINVAL;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
- INIT_LIST_HEAD(&cb->node);
+ INIT_LIST_HEAD(&cb->node);
+ cb->func = func;
+
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return -ENOENT;
- }
spin_lock_irqsave(fence->lock, flags);
-
- was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
- &fence->flags);
-
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
- ret = -ENOENT;
- else if (!was_set && fence->ops->enable_signaling) {
+ if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags) &&
+ !test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
+ &fence->flags)) {
trace_dma_fence_enable_signal(fence);
- if (!fence->ops->enable_signaling(fence)) {
+ if (!fence->ops->enable_signaling ||
+ fence->ops->enable_signaling(fence)) {
+ list_add_tail(&cb->node, &fence->cb_list);
+ ret = 0;
+ } else {
dma_fence_signal_locked(fence);
- ret = -ENOENT;
}
}
-
- if (!ret) {
- cb->func = func;
- list_add_tail(&cb->node, &fence->cb_list);
- } else
- INIT_LIST_HEAD(&cb->node);
spin_unlock_irqrestore(fence->lock, flags);
return ret;
Not a whole lot changes in terms of branches and serialising
instructions. One less baffling sequence to worry about.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"
== Series Details ==
Series: Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"
URL : https://patchwork.freedesktop.org/series/65267/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6712 -> Patchwork_14034
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14034/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14034:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_chamelium@hdmi-hpd-fast:
- {fi-icl-u4}:[FAIL][1] ([fdo#111045]) -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14034/fi-icl-u4/igt@kms_chamel...@hdmi-hpd-fast.html
Known issues
Here are the changes found in Patchwork_14034 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14034/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
Possible fixes
* igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][5] ([fdo#111045]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6712/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14034/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
Participating hosts (53 -> 42)
--
Additional (1): fi-gdg-551
Missing(12): fi-kbl-soraka fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u
fi-byt-squawks fi-bsw-cyan fi-hsw-4770 fi-pnv-d510 fi-icl-y fi-icl-guc
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6712 -> Patchwork_14034
CI-20190529: 20190529
CI_DRM_6712: cd7b3a5a9d3b20684a62b8c1a33707c162ee3629 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5138: b9abe0bf6c478c4f6cac56bff286d6926ad8c0ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14034: d4ceec6bc2106009e318f4937bf0a86d07a5b969 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d4ceec6bc210 Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14034/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] kernel.h: Add non_block_start/end()
On Thu 15-08-19 15:24:48, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 07:42:07PM +0200, Michal Hocko wrote:
> > On Thu 15-08-19 13:56:31, Jason Gunthorpe wrote:
> > > On Thu, Aug 15, 2019 at 06:00:41PM +0200, Michal Hocko wrote:
> > >
> > > > > AFAIK 'GFP_NOWAIT' is characterized by the lack of __GFP_FS and
> > > > > __GFP_DIRECT_RECLAIM..
> > > > >
> > > > > This matches the existing test in __need_fs_reclaim() - so if you are
> > > > > OK with GFP_NOFS, aka __GFP_IO which triggers try_to_compact_pages(),
> > > > > allocations during OOM, then I think fs_reclaim already matches what
> > > > > you described?
> > > >
> > > > No GFP_NOFS is equally bad. Please read my other email explaining what
> > > > the oom_reaper actually requires. In short no blocking on direct or
> > > > indirect dependecy on memory allocation that might sleep.
> > >
> > > It is much easier to follow with some hints on code, so the true
> > > requirement is that the OOM repear not block on GFP_FS and GFP_IO
> > > allocations, great, that constraint is now clear.
> >
> > I still do not get why do you put FS/IO into the picture. This is really
> > about __GFP_DIRECT_RECLAIM.
>
> Like I said this is complicated, translating "no blocking on direct or
> indirect dependecy on memory allocation that might sleep" into GFP
> flags is hard for us outside the mm community.
>
> So the contraint here is no __GFP_DIRECT_RECLAIM?
OK, I am obviously failing to explain that. Sorry about that. You are
right that this is not simple. Let me try again.
The context we are calling !blockable notifiers from has to finish in a
_finite_ amount of time (and swift is hugely appreciated by users of
otherwise non-responsive system that is under OOM). We are out of memory
so we cannot be blocked waiting for memory. Directly or indirectly (via
a lock, waiting for an event that needs memory to finish in general). So
you need to track dependency over more complicated contexts than the
direct call path (think of workqueue for example).
> I bring up FS/IO because that is what Tejun mentioned when I asked him
> about reclaim restrictions, and is what fs_reclaim_acquire() is
> already sensitive too. It is pretty confusing if we have places using
> the word 'reclaim' with different restrictions. :(
fs_reclaim has been invented to catch potential deadlocks when a
GFP_NO{FS/IO} allocation hits into fs/io reclaim. This is a subset of
the reclaim that we have. The oom context is more restricted and it
cannot depend on _any_ memory reclaim because by the time we have got to
this context all the reclaim has already failed and wait some more will
simply not help.
> > >CPU0 CPU1
> > > mutex_lock()
> > > kmalloc(GFP_KERNEL)
> >
> > no I mean __GFP_DIRECT_RECLAIM here.
> >
> > > mutex_unlock()
> > > fs_reclaim_acquire()
> > > mutex_lock() <- illegal: lock dep assertion
> >
> > I cannot really comment on how that is achieveable by lockdep.
>
> ??? I am trying to explain this is already done and working today. The
> above example will already fault with lockdep enabled.
>
> This is existing debugging we can use and improve upon rather that
> invent new debugging.
This is what you claim and I am saying that fs_reclaim is about a
restricted reclaim context and it is an ugly hack. It has proven to
report false positives. Maybe it can be extended to a generic reclaim.
I haven't tried that. Do not aim to try it.
--
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "ALSA: hda - Drop unsol event handler for Intel HDMI codecs"
Quoting Chris Wilson (2019-08-15 19:15:51) > In the recent snd merge of > > ddf7cb83b0f4 ALSA: hda: Unexport a few more stuff > 53eff75e5f4d ALSA: hda: Drop export of snd_hdac_bus_add/remove_device() > ee5f85d9290f ALSA: hda: Add codec on bus address table lately > f2dbe87c5ac1 ALSA: hda - Drop unsol event handler for Intel HDMI codecs > > module unload dies on all a couple of machines with > > <1> [281.912684] BUG: kernel NULL pointer dereference, address: > > <1> [281.912697] #PF: supervisor read access in kernel mode > <1> [281.912703] #PF: error_code(0x) - not-present page > <6> [281.912709] PGD 0 P4D 0 > <4> [281.912714] Oops: [#1] PREEMPT SMP PTI > <4> [281.912721] CPU: 3 PID: 2842 Comm: i915_module_loa Tainted: G U > 5.3.0-rc4-CI-CI_DRM_6712+ #1 > <4> [281.912730] Hardware name: Hewlett-Packard HP EliteBook 8440p/172A, BIOS > 68CCU Ver. F.24 09/13/2013 > <4> [281.912744] RIP: 0010:__list_del_entry_valid+0x25/0x90 > <4> [281.912751] Code: c3 0f 1f 40 00 48 8b 07 48 b9 00 01 00 00 00 00 ad de > 48 8b 57 08 48 39 c8 74 26 48 b9 22 01 00 00 00 00 ad de 48 39 ca 74 2e <48> > 8b 32 48 39 fe 75 3a 48 8b 50 08 48 39 f2 75 48 b8 01 00 00 00 > <4> [281.912767] RSP: 0018:c972bca8 EFLAGS: 00010217 > <4> [281.912774] RAX: RBX: 88812f8933f8 RCX: > dead0122 > <4> [281.912782] RDX: RSI: 88812f8933f8 RDI: > 88812f8938a8 > <4> [281.912789] RBP: 88812e7ce7e8 R08: R09: > > <4> [281.912796] R10: R11: R12: > 88812f8938a8 > <4> [281.912803] R13: 88812c8722a8 R14: c972bf08 R15: > 888129761df8 > <4> [281.912811] FS: 7fb4913a9e40() GS:888133b8() > knlGS: > <4> [281.912819] CS: 0010 DS: ES: CR0: 80050033 > <4> [281.912826] CR2: CR3: 00012867a000 CR4: > 06e0 > <4> [281.912833] Call Trace: > <4> [281.912844] snd_hdac_bus_remove_device+0x2e/0xb0 [snd_hda_core] > <4> [281.912854] snd_hdac_device_exit+0x31/0x60 [snd_hda_core] > <4> [281.912866] snd_hda_codec_dev_release+0x24/0x50 [snd_hda_codec] > <4> [281.912876] device_release+0x22/0x80 > <4> [281.912883] kobject_put+0x86/0x1b0 > <4> [281.912891] snd_hda_codec_dev_free+0x5c/0x60 [snd_hda_codec] > <4> [281.912899] __snd_device_free+0x4a/0x80 > <4> [281.912904] snd_device_free_all+0x36/0x90 > <4> [281.912911] release_card_device+0x14/0x60 > <4> [281.912917] device_release+0x22/0x80 > <4> [281.912923] kobject_put+0x86/0x1b0 > <4> [281.912928] snd_card_free+0x60/0x90 > <4> [281.912939] pci_device_remove+0x36/0xb0 > <4> [281.912946] device_release_driver_internal+0xd3/0x1b0 > <4> [281.912953] unbind_store+0xc3/0x120 > <4> [281.912962] kernfs_fop_write+0x104/0x190 > <4> [281.912971] vfs_write+0xbd/0x1d0 > <4> [281.912977] ksys_write+0x8f/0xe0 > <4> [281.912984] do_syscall_64+0x55/0x1c0 It wasn't f2dbe87c5ac1 ALSA: hda - Drop unsol event handler for Intel HDMI codecs -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Enabling DSC on Pipe A for TGL
On Thu, 2019-08-15 at 11:53 -0700, Manasi Navare wrote:
> On Thu, Aug 15, 2019 at 11:39:54AM -0700, Tolakanahalli Pradeep,
> Madhumitha wrote:
> > On Thu, 2019-08-15 at 11:24 -0700, Manasi Navare wrote:
> > > On Wed, Aug 14, 2019 at 04:51:17PM -0700, Madhumitha
> > > Tolakanahalli
> > > Pradeep wrote:
> > > > Removing restriction on Pipe A as TigerLake onwards, all the
> > > > pipes
> > > > support DSC.
> > >
> > > May be elaborate this commit message a little bit something like:
> > > "On previous platforms, DSC was not supported on Pipe A while
> > > starting TGL, its is supported
> > > on all pipes. So remove the DSC and FEC restriction on Pipe A for
> > > TGL
> > > onwards.
> > >
> >
> > Alright, will update that for rev2.
> >
> > > >
> > > > Cc: Manasi Navare
> > > > Signed-off-by: Madhumitha Tolakanahalli Pradeep <
> > > > madhumitha.tolakanahalli.prad...@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp.c | 16
> > > > 1 file changed, 12 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > index 4884c87c8ed7..a5b50f93fac5 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > > @@ -1739,8 +1739,12 @@ static bool
> > > > intel_dp_source_supports_fec(struct intel_dp *intel_dp,
> > > > {
> > > > struct drm_i915_private *dev_priv =
> > > > dp_to_i915(intel_dp);
> > > >
> > > > - return INTEL_GEN(dev_priv) >= 11 &&
> > > > - pipe_config->cpu_transcoder != TRANSCODER_A;
> > > > + /* On TGL, DSC is supported on all Pipes */
> > >
> > > FEC supported on all pipes
> >
> > Oops, will change this.
> >
> > > > + if (INTEL_GEN(dev_priv) >= 12)
> > > > + return true;
> > > > + else
> > > > + return INTEL_GEN(dev_priv) == 11 &&
>
> Also here I think its better to use IS_GEN(dev_priv, 11)
Yes, that does make it clearer, I'll change it for v2.
>
> > > > + pipe_config->cpu_transcoder !=
> > > > TRANSCODER_A;
> > > > }
> > > >
> > > > static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
> > > > @@ -1755,8 +1759,12 @@ static bool
> > > > intel_dp_source_supports_dsc(struct intel_dp *intel_dp,
> > > > {
> > > > struct drm_i915_private *dev_priv =
> > > > dp_to_i915(intel_dp);
> > > >
> > > > - return INTEL_GEN(dev_priv) >= 10 &&
> > > > - pipe_config->cpu_transcoder != TRANSCODER_A;
> > > > + /* On TGL, DSC is supported on all Pipes */
> > > > + if (INTEL_GEN(dev_priv) >= 12)
> > > > + return true;
> > > > + else
> > > > + return (INTEL_GEN(dev_priv) == 10 ||
> > > > INTEL_GEN(dev_priv) == 11) &&
> > >
> > > Why cant you just use INTEL_GEN(dev_priv) >=10 ?
> >
> > INTEL_GEN(dev_priv) >= 10 was the existing condition. With the new
> > condition added, there would be an overlapping set
> > ie INTEL_GEN(dev_priv) >= 10 would still be TRUE for GEN >= 12.
> > Though
> > this wouldn't affect the logic of the code, thought it would make
> > more
> > sense to sperate it out this way.
>
> But since we return for GEN >=12 , the only time it would fall to GEN
> >=10 is for 10 and 11
> so that should work, or you could use IS_GEN(dev_priv, 10) ||
> IS_GEN(dev_priv, 11)
>
> But may be check with Lucas on what would be the preferred way
Yeah, it wouldn't affect the logic. I debated about it for a while too.
@Lucas, what do you think is the preferred way to implement this?
>
> Manasi
> >
> > >
> > > Manasi
> > >
> > > > + pipe_config->cpu_transcoder !=
> > > > TRANSCODER_A;
> > > > }
> > > >
> > > > static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> > > > --
> > > > 2.17.1
> > > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drm/i915/gt: Guard timeline pinning with its own mutex
On Wed, 14 Aug 2019 at 10:28, Chris Wilson wrote: > > In preparation for removing struct_mutex from around context retirement, > we need to make timeline pinning safe. Since multiple engines/contexts > can share a single timeline, it needs to be protected by a mutex. > > Signed-off-by: Chris Wilson With a more accurate commit message, Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v5] dma-fence: Propagate errors to dma-fence-array container (rev7)
== Series Details == Series: series starting with [v5] dma-fence: Propagate errors to dma-fence-array container (rev7) URL : https://patchwork.freedesktop.org/series/65027/ State : failure == Summary == Applying: dma-fence: Propagate errors to dma-fence-array container Using index info to reconstruct a base tree... M drivers/dma-buf/dma-fence-array.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: dma-fence: Report the composite sync_file status Using index info to reconstruct a base tree... M drivers/dma-buf/sync_file.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: dma-fence: Refactor signaling for manual invocation Using index info to reconstruct a base tree... M drivers/dma-buf/Makefile M drivers/dma-buf/dma-fence.c M drivers/gpu/drm/i915/gt/intel_breadcrumbs.c M include/linux/dma-fence.h Falling back to patching base and 3-way merge... Auto-merging include/linux/dma-fence.h Auto-merging drivers/gpu/drm/i915/gt/intel_breadcrumbs.c Auto-merging drivers/dma-buf/dma-fence.c Auto-merging drivers/dma-buf/Makefile CONFLICT (content): Merge conflict in drivers/dma-buf/Makefile error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0003 dma-fence: Refactor signaling for manual invocation 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 5/4] dma-fence: Have dma_fence_signal call signal_locked
Quoting Chris Wilson (2019-08-15 20:03:13)
> Quoting Daniel Vetter (2019-08-15 19:48:42)
> > On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson
> > wrote:
> > > Quoting Daniel Vetter (2019-08-14 18:20:53)
> > > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> > > > > Now that dma_fence_signal always takes the spinlock to flush the
> > > > > cb_list, simply take the spinlock and call dma_fence_signal_locked()
> > > > > to
> > > > > avoid code repetition.
> > > > >
> > > > > Suggested-by: Christian König
> > > > > Signed-off-by: Chris Wilson
> > > > > Cc: Christian König
> > > >
> > > > Hm, I think this largely defeats the point of having the lockless signal
> > > > enabling trickery in dma_fence. Maybe that part isn't needed by anyone,
> > > > but feels like a thing that needs a notch more thought. And if we need
> > > > it,
> > > > maybe a bit more cleanup.
> > >
> > > You mean dma_fence_enable_sw_signaling(). The only user appears to be to
> > > flush fences, which is actually the intent of always notifying the signal
> > > cb. By always doing the callbacks, we can avoid installing the interrupt
> > > and completely saturating CPUs with irqs, instead doing a batch in a
> > > leisurely timer callback if not flushed naturally.
> >
> > Yeah I'm not against ditching this,
>
> I was just thinking aloud working out what the current use case in ttm
> was for.
>
> > but can't we ditch a lot more if
> > we just always take the spinlock in those paths now anyways? Kinda not
> > worth having the complexity anymore.
>
> You would be able to drop the was_set from dma_fence_add_callback. Say
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 59ac96ec7ba8..e566445134a2 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -345,38 +345,31 @@ int dma_fence_add_callback(struct dma_fence *fence,
> struct dma_fence_cb *cb,
>dma_fence_func_t func)
> {
> unsigned long flags;
> - int ret = 0;
> - bool was_set;
> + int ret = -ENOENT;
>
> if (WARN_ON(!fence || !func))
> return -EINVAL;
>
> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> - INIT_LIST_HEAD(&cb->node);
> + INIT_LIST_HEAD(&cb->node);
> + cb->func = func;
> +
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> return -ENOENT;
> - }
>
> spin_lock_irqsave(fence->lock, flags);
> -
> - was_set = test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
> - &fence->flags);
> -
> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> - ret = -ENOENT;
> - else if (!was_set && fence->ops->enable_signaling) {
> + if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags) &&
> + !test_and_set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
> + &fence->flags)) {
> trace_dma_fence_enable_signal(fence);
>
> - if (!fence->ops->enable_signaling(fence)) {
> + if (!fence->ops->enable_signaling ||
> + fence->ops->enable_signaling(fence)) {
> + list_add_tail(&cb->node, &fence->cb_list);
> + ret = 0;
> + } else {
> dma_fence_signal_locked(fence);
> - ret = -ENOENT;
> }
> }
> -
> - if (!ret) {
> - cb->func = func;
> - list_add_tail(&cb->node, &fence->cb_list);
> - } else
> - INIT_LIST_HEAD(&cb->node);
> spin_unlock_irqrestore(fence->lock, flags);
>
> return ret;
>
> Not a whole lot changes in terms of branches and serialising
> instructions. One less baffling sequence to worry about.
Fwiw,
Function old new delta
dma_fence_add_callback 338 302 -36
Almost certainly more shaving if you stare.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
