Quoting Chris Wilson (2019-08-05 16:58:56)
> Quoting Christian König (2019-08-05 16:45:50)
> > The reservation object should be capable of handling its internal memory
> > management itself. And since we search for a free slot to add the fence
> > from the beginning thi
Quoting Christian König (2019-08-05 16:45:54)
> @@ -214,16 +214,16 @@ static __poll_t dma_buf_poll(struct file *file,
> poll_table *poll)
> return 0;
>
> retry:
> - seq = read_seqcount_begin(>seq);
> rcu_read_lock();
>
> + fence_excl =
Quoting Christian König (2019-08-05 16:45:50)
> The reservation object should be capable of handling its internal memory
> management itself. And since we search for a free slot to add the fence
> from the beginning this is actually a waste of time and only minimal helpful.
"From the beginning?"
Prior to making the syncobj lookup lockless, update the idr to the new
XArray API.
Based on a patch by Matthew Wilcox
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 64 ++-
include/drm/drm_file.h| 7 ++--
2 files changed, 21 insertions
our reference.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 12 +---
include/drm/drm_syncobj.h | 2 ++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4fc71dc9fc43
Quoting Sergey Senozhatsky (2019-08-02 14:49:55)
> On (08/02/19 14:41), Chris Wilson wrote:
> [..]
> > struct vfsmount *kern_mount(struct file_system_type *type)
> > {
> > struct vfsmount *mnt;
> > mnt = vfs_kern_mount(type, SB_KERNMOUNT, type->nam
Quoting Sergey Senozhatsky (2019-08-02 14:35:03)
> On (08/02/19 22:15), Sergey Senozhatsky wrote:
> [..]
> > > > Looking around, it looks like we always need to drop type after
> > > > mounting. Should the
> > > > put_filesystem(type);
> > > > be here instead?
> > > >
> > > > Anyway, nice
Quoting Chris Wilson (2019-08-02 13:58:36)
> Quoting Sergey Senozhatsky (2019-08-02 13:39:56)
> > put_filesystem() before i915_gemfs_init() deals with
> > kern_mount() error.
> >
> > Signed-off-by: Sergey Senozhatsky
> > ---
> > drivers/gpu/drm/i915/gem/i9
Quoting Sergey Senozhatsky (2019-08-02 13:39:56)
> put_filesystem() before i915_gemfs_init() deals with
> kern_mount() error.
>
> Signed-off-by: Sergey Senozhatsky
> ---
> drivers/gpu/drm/i915/gem/i915_gemfs.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git
> + ok = false;
> }
>
> +out:
> + if (!ok)
> + pr_err("i915 gemfs reconfiguration failed\n");
Let's make it a bit more user friendly,
dev_err(i915->drm.dev,
"Unable to reconfigure internal shmemfs for pre
Quoting Sergey Senozhatsky (2019-07-31 17:48:29)
> @@ -36,19 +38,35 @@ int i915_gemfs_init(struct drm_i915_private *i915)
> struct super_block *sb = gemfs->mnt_sb;
> /* FIXME: Disabled until we get W/A for read BW issue. */
> char options[] =
Quoting Rob Clark (2019-08-01 16:18:45)
> On Thu, Aug 1, 2019 at 5:40 AM Chris Wilson wrote:
> >
> > Quoting Sean Paul (2019-07-31 20:23:31)
> > > On Fri, Jul 19, 2019 at 11:21:53AM +0200, Daniel Vetter wrote:
> > > > On Wed, Jul 17, 2019 at 02:15:37PM -0700,
commit 7e9e5ead55be ("drm/vgem: fix cache synchronization on arm/arm64")
broke all of the !llc i915-vgem coherency tests in CI, and left the HW
very, very unhappy (which is even more scary).
Fixes: 7e9e5ead55be ("drm/vgem: fix cache synchronization on arm/arm64")
Signed-off-
Quoting Sean Paul (2019-07-31 20:23:31)
> On Fri, Jul 19, 2019 at 11:21:53AM +0200, Daniel Vetter wrote:
> > On Wed, Jul 17, 2019 at 02:15:37PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > drm_cflush_pages() is no-op on arm/arm64. But instead we can use
> > > dma_sync API.
> > >
>
Quoting Christian König (2019-07-31 14:34:28)
> Am 31.07.19 um 14:33 schrieb Chris Wilson:
> > Quoting Christian König (2019-07-31 12:38:53)
> >> Complete the abstraction of the ww_mutex inside the reservation object.
> >>
> >> This allows us to add more handl
chanical,
Reviewed-by: Chris Wilson
Quietly opines for s/reservation_object/dma_reservation/
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
\
> +(fence = dma_fence_chain_unwrap(iter));\
> +iter = dma_fence_chain_walk(iter))
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Christian König (2019-07-30 13:15:53)
> +/**
> + * dma_fence_chain_unwrap - unwrap chain node
> + * @fence: fence which could be a chain node
> + *
> + * If the paramter is a chain node return the cotained fence, otherwise
> return
> + * the parameter itself.
> + */
s/paramter/parameter/
Quoting Thomas Gleixner (2019-07-26 20:18:32)
> On Fri, 26 Jul 2019, Chris Wilson wrote:
> > Quoting Thomas Gleixner (2019-07-25 22:55:45)
> > > On Thu, 25 Jul 2019, Josh Poimboeuf wrote:
> > >
> > > > Objtool reports:
> > > >
> > >
Quoting Thomas Gleixner (2019-07-25 22:55:45)
> On Thu, 25 Jul 2019, Josh Poimboeuf wrote:
>
> > Objtool reports:
> >
> > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
> > .altinstr_replacement+0x36: redundant UACCESS disable
> >
> > __copy_from_user() already does both
Quoting Chenbo Feng (2019-06-13 23:34:07)
> From: Greg Hackmann
>
> This patch adds complimentary DMA_BUF_SET_NAME ioctls, which lets
> userspace processes attach a free-form name to each buffer.
>
> This information can be extremely helpful for tracking and accounting
> shared buffers. For
Quoting Chris Wilson (2019-07-23 17:25:17)
> Quoting Chuhong Yuan (2019-07-23 11:39:16)
> > Instead of using to_pci_dev + pci_get_drvdata,
> > use dev_get_drvdata to make code simpler.
> >
> > Signed-off-by: Chuhong Yuan
>
> That cuts out some circumlocu
Quoting Chuhong Yuan (2019-07-23 11:39:16)
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan
That cuts out some circumlocution,
Reviewed-by: Chris Wilson
-Chris
xport with obj_funcs.export
>
> plus make sure i915_gem_dma_buf.c doesn't get zombie-resurrect. It
> moved in
>
> commit 10be98a77c558f8cfb823cd2777171fbb35040f6
> Author: Chris Wilson
> Date: Tue May 28 10:29:49 2019 +0100
>
> drm/i915: Move more GEM obj
xport with obj_funcs.export
>
> plus make sure i915_gem_dma_buf.c doesn't get zombie-resurrect. It
> moved in
>
> commit 10be98a77c558f8cfb823cd2777171fbb35040f6
> Author: Chris Wilson
> Date: Tue May 28 10:29:49 2019 +0100
>
> drm/i915: Move more GEM object
between include/drm/* and uapi/*
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Daniel Vetter
> Reviewed-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Chris Wilson
> Cc:
Quoting Chunming Zhou (2019-07-18 14:15:49)
>
> 在 2019/7/18 21:10, Chris Wilson 写道:
> > Quoting Chunming Zhou (2019-07-18 14:04:09)
> >> 在 2019/7/18 19:18, Chris Wilson 写道:
> >>> Quoting Chunming Zhou (2019-07-18 12:13:39)
> >>>> if WAIT_FOR_SUB
Quoting Chunming Zhou (2019-07-18 14:04:09)
>
> 在 2019/7/18 19:18, Chris Wilson 写道:
> > Quoting Chunming Zhou (2019-07-18 12:13:39)
> >> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
> >> syncobj,
> >> then return non-block err
Quoting Chunming Zhou (2019-07-18 12:13:39)
> if WAIT_FOR_SUBMIT isn't set and in the meanwhile no underlying fence on
> syncobj,
> then return non-block error code to user sapce.
Block device required?
I presume you tried the EWOULDBLOCK which would be implied by your
sentence and found that
Quoting Daniel Vetter (2019-07-16 10:21:54)
> On Fri, Jul 12, 2019 at 09:03:14AM +0100, Chris Wilson wrote:
> > As the set of shared fences is not being changed during reallocation of
> > the reservation list, we can skip updating the write_seqlock.
> >
> > Signed-o
Quoting Rob Clark (2019-07-16 18:43:22)
> From: Rob Clark
>
> Needed in the following patch for cache operations.
What's the base for this patch? (I'm missing the ancestor for drm_gem.c)
-Chris
___
dri-devel mailing list
Quoting Rob Clark (2019-07-16 17:42:15)
> From: Rob Clark
>
> Since there is no real device associated with vgem, it is impossible to
> end up with appropriate dev->dma_ops, meaning that we have no way to
> invalidate the shmem pages allocated by vgem. So, at least on platforms
> without
Quoting Chris Wilson (2019-07-12 09:03:13)
> Since kmalloc() will round up the allocation to the next slab size or
> page, it will normally return a pointer to a memory block bigger than we
> asked for. We can query for the actual size of the allocated block using
> ksize() and expand
Quoting Koenig, Christian (2019-07-14 08:37:47)
> Am 12.07.19 um 10:03 schrieb Chris Wilson:
> > Since kmalloc() will round up the allocation to the next slab size or
> > page, it will normally return a pointer to a memory block bigger than we
> > asked for. We can quer
Quoting Daniel Vetter (2019-07-12 13:51:58)
> On Fri, Jul 12, 2019 at 2:01 PM Chris Wilson wrote:
> >
> > A buffer is created in response to the user ioctl, it should therefore
> > be a plain DRM_DEBUG() message to reflect it being a user invoked
> > response
A buffer is created in response to the user ioctl, it should therefore
be a plain DRM_DEBUG() message to reflect it being a user invoked
response and not a driver construct.
This is just to make the commonplace drm.debug=[26e] quieter when
running with vgem.
Signed-off-by: Chris Wilson
Cc
As the set of shared fences is not being changed during reallocation of
the reservation list, we can skip updating the write_seqlock.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Christian König
---
drivers/dma-buf/reservation.c | 14 +++---
1 file changed, 7 insertions(+), 7
of that extra space.
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Michel Dänzer
---
drivers/dma-buf/reservation.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index a6ac2b3a0185..80ecc1283d15 100644
xtern header churn.
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Janusz Krzysztofik (2019-07-10 15:59:55)
> Follow dim checkpatch recommendations so it doesn't complain now and
> again on consistent modifications of i915_params.c
This is one where we've considered the merits of not rigorously applying
checkpatch.pl and adopted a different convention.
Quoting Janusz Krzysztofik (2019-07-10 15:52:39)
> Follow dim checkpatch recommendation so it doesn't complain on that now
> and again on header file modifications.
>
> Signed-off-by: Janusz Krzysztofik
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@
Quoting Janusz Krzysztofik (2019-07-10 13:36:25)
> Need for this was identified while working on split of driver unbind
> path into _remove() and _release() parts. Consistency in function
> naming has been recognized as helpful when trying to work out which
> phase the code is in.
>
> What I'm
Quoting Janusz Krzysztofik (2019-07-09 07:58:00)
> Commit e163484afa8d ("drm/i915: Update size upon return from
> GEM_CREATE") (re)introduced reporting of actual size of created GEM
> objects, possibly rounded up on object alignment. Unfortunately, its
> implementation resulted in a possible
We gracefully handle the caller specifying a zero range, so don't force
them to special case that condition if it naturally falls out of their
setup. What we don't check is if the end < start, so keep that as an
assert for an illegal call.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
ot;drm: Add reservation_object to drm_gem_object")
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
Quick leave before I start ranting about the horrors of
reservation_object.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Quoting Steven Rostedt (2019-06-14 14:39:14)
> I'm trying to debug some code where I need KASAN and lockdep enabled
> but I can't get past this splat unrelated to my code. I bisected it
> down to this commit:
>
> 32eb6bcfdda9da ("drm/i915: Make request allocation caches global")
>
> To make
Quoting Rob Herring (2019-06-10 18:04:40)
> The midgard/bifrost GPUs need to allocate GPU memory which is allocated
> on GPU page faults and not pinned in memory. The vendor driver calls
> this functionality GROW_ON_GPF.
>
> This implementation assumes that BOs allocated with the
>
Quoting Patchwork (2019-06-12 15:07:50)
> == Series Details ==
>
> Series: dma-fence/reservation: Markup rcu protected access for DEBUG_MUTEXES
> URL : https://patchwork.freedesktop.org/series/61963/
> State : warning
>
> == Summary ==
>
> $ dim sparse origin/drm-tip
> Sparse version: v0.5.2
Mark the access to reservation_object.fence as being protected to
silence sparse.
Signed-off-by: Chris Wilson
---
include/linux/reservation.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index ee750765cc94
Quoting Daniel Vetter (2019-06-11 12:28:59)
> Apparently little none fact that there's no need to hand-roll your own
s/none/known/
> anymore. Cc'ing a bunch of driver people who might want to know this
> too.
___
dri-devel mailing list
up, and if they care they can check for the error.
Signed-off-by: Chris Wilson
Reviewed-by: Gustavo Padovan
---
drivers/dma-buf/dma-fence.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index
up, and if they care they can check for the error.
Signed-off-by: Chris Wilson
Reviewed-by: Gustavo Padovan
---
drivers/dma-buf/dma-fence.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index
If we have to drop the seqcount & rcu lock to perform a krealloc, we
have to restart the loop. In doing so, be careful not to lose track of
the already acquired exclusive fence.
Fixes: fedf54132d24 ("dma-buf: Restart reservation_object_get_fences_rcu()
after writes") #v4.10
Signed
If we have to drop the seqcount & rcu lock to perform a krealloc, we
have to restart the loop. In doing so, be careful not to lose track of
the already acquired exclusive fence.
Fixes: fedf54132d24 ("dma-buf: Restart reservation_object_get_fences_rcu()
after writes") #v4.10
Signed
If we have to drop the seqcount & rcu lock to perform a krealloc, we
have to restart the loop. In doing so, be careful not to lose track of
the already acquired exclusive fence.
Fixes: fedf54132d24 ("dma-buf: Restart reservation_object_get_fences_rcu()
after writes") #v4.10
Signed
52] Call Trace:
<4> [341.890760] drm_fb_helper_hotplug_event.part.24+0x89/0xb0
<4> [341.890768] drm_kms_helper_hotplug_event+0x21/0x30
<4> [341.890774] output_poll_execute+0x9d/0x1a0
<4> [341.890782] process_one_work+0x245/0x610
<4> [341.890790] worker_thread+0x37/0x38
52] Call Trace:
<4> [341.890760] drm_fb_helper_hotplug_event.part.24+0x89/0xb0
<4> [341.890768] drm_kms_helper_hotplug_event+0x21/0x30
<4> [341.890774] output_poll_execute+0x9d/0x1a0
<4> [341.890782] process_one_work+0x245/0x610
<4> [341.890790] worker_thread+0x37/0
Quoting Chris Wilson (2019-05-31 18:16:15)
> We need to mark the output polling as disabled to prevent concurrent
> irqs from queuing new work as shutdown the probe -- causing that work to
> execute after we have freed the structs:
>
> <4> [341.846490] DEBUG_LOCKS_WARN_ON
00708 R15:
0007
<4> [341.890730] FS: () GS:88827620()
knlGS:
<4> [341.890739] CS: 0010 DS: ES: CR0: 80050033
<4> [341.890745] CR2: 55a4e064f4a0 CR3: 00026d234003 CR4:
003606f0
<4> [341.890752] C
Quoting Colin King (2019-05-31 11:32:01)
> From: Colin Ian King
>
> The assignment of err is using the incorrect pointer vaddr that has
> not been initialized. Fix this by using the correct pointer obj instead.
>
> Addresses-Coverity: ("Uninitialized pointer read")
> Fixes: 6501aa4e3a45
pure cleanup. So for the time being, best to
leave intel_uc_fini() here.
> + mutex_unlock(_priv->drm.struct_mutex);
> +
> + i915_gem_drain_freed_objects(dev_priv);
> +}
> +
> +void i915_gem_fini(struct drm_i915_private *dev_priv)
> +{
> + mutex_lock(_priv->drm.struct_mutex);
> i915_gem_contexts_fini(dev_priv);
> i915_gem_fini_scratch(dev_priv);
> mutex_unlock(_priv->drm.struct_mutex);
That split looks sensible to me, with the consideration as to whether
defer intel_engines_cleanup() as well,
Reviewed-by: Chris Wilson
-Chris
Quoting Chris Wilson (2019-05-29 12:06:57)
> Quoting Dan Carpenter (2019-05-29 12:03:55)
> > We should check "request[n]" instead of just "request".
> >
> > Fixes: 78e41ddd2198 ("drm/i915: Apply an execution_mask to the
> > virtual_engine"
Quoting Dan Carpenter (2019-05-29 12:03:55)
> We should check "request[n]" instead of just "request".
>
> Fixes: 78e41ddd2198 ("drm/i915: Apply an execution_mask to the
> virtual_engine")
> Signed-off-by: Dan Carpe
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: d3622099c76f ("drm/i915/gtt: Always acquire struct_mutex for
> gen6_ppgtt_cleanup")
> Signed-off-by: Colin Ian King
Saw that last night but got distracted by the panic-on-boot...
Reviewed-by: Chris Wilson
-Chris
Quoting Dongli Zhang (2019-05-21 05:40:39)
> This patch removes IO_TLB_SEGPAGES which is no longer used since
> commit 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen").
>
> As the define of both IO_TLB_SEGSIZE and IO_TLB_SHIFT are from swiotlb,
> IO_TLB_SEGPAGES should be defined on
Quoting Michal Hocko (2019-05-22 07:34:42)
> On Wed 22-05-19 06:06:31, Tetsuo Handa wrote:
> [...]
> > Since OOM notifier will be called after shrinkers are attempted,
> > can i915 move from OOM notifier to shrinker?
>
> That would be indeed preferable. OOM notifier is an API from hell.
We
Quoting Rob Herring (2019-05-21 16:24:27)
> On Mon, May 20, 2019 at 4:23 AM Steven Price wrote:
> >
>
> You forgot to update the subject. I can fixup when applying, but I'd
> like an ack from Chris on patch 1.
I still think it is incorrect as the limitation is purely an issue with
the shmem
the history to trawl through.
References: 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen")
> Signed-off-by: Dongli Zhang
Reviewed-by: Chris Wilson
-Chris
Quoting Janusz Krzysztofik (2019-05-17 15:06:17)
> From: Janusz Krzysztofik
>
> During i915_driver_unload(), GEM contexts are verified restrictively
> inside i915_gem_fini() if they don't consume shared resources which
> should be cleaned up before the driver is released. If those checks
>
Quoting Masahiro Yamada (2019-05-15 05:37:53)
> The top level Makefile adds -Wall globally:
>
> KBUILD_CFLAGS := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
>
> I see two "-Wall" added for compiling under drivers/gpu/drm/i915/.
Does it matter? Is the statement in i915/Makefile
Quoting Michael Yang (2019-05-14 08:55:37)
> On Thu, May 09, 2019 at 12:46:05PM +0100, Chris Wilson wrote:
> > Quoting Michael Yang (2019-05-09 05:34:11)
> > > If all the sync points were signaled in both fences a and b,
> > > there was only one sync point in merg
Quoting Steven Price (2019-05-13 16:14:01)
> On 13/05/2019 15:47, Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-05-13 15:39:21)
> >> On Mon, May 13, 2019 at 03:32:44PM +0100, Steven Price wrote:
> >>> panfrost_ioctl_mmap_bo() contains a reimplementation of
Quoting Daniel Vetter (2019-05-13 15:39:21)
> On Mon, May 13, 2019 at 03:32:44PM +0100, Steven Price wrote:
> > panfrost_ioctl_mmap_bo() contains a reimplementation of
> > drm_gem_dump_map_offset() but with a bug - it allows mapping imported
> > objects (without going through the exporter). Fix
y: Daniel Vetter
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Will Deacon
> Cc: Petr Mladek
> Cc: Sergey Senozhatsky
> Cc: Steven Rostedt
> Cc: Daniel Vetter
> Cc: John Ogness
> Cc: Chris Wilson
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by:
Quoting Michael Yang (2019-05-09 05:34:11)
> If all the sync points were signaled in both fences a and b,
> there was only one sync point in merged fence which is a_fence[0].
> The Fence structure in android framework might be confused about
> timestamp if there were any sync points which were
Quoting Daniel Vetter (2019-05-08 13:53:30)
> On Wed, May 8, 2019 at 2:06 PM Chris Wilson wrote:
> >
> > Currently there is an underlying assumption that i915_request_unsubmit()
> > is synchronous wrt the GPU -- that is the request is no longer in flight
> > as we re
Quoting Chris Wilson (2019-05-08 13:05:42)
> Move the duplicated code within dma-fence.c into the header for wider
> reuse. In the process apply a small micro-optimisation to only prune the
> fence->cb_list once rather than use list_del on every entry.
>
> Signed-off-by: Chris
In order to fix a bug in i915, I would like to opencode the dma fence
signal processing (to close a race condition with preemption and signal
enabling). Tvrtko quite rightly objected to the opencoding and suggested
that dma-fence should provide the helpers, so here's my suggestion wrt
the
"drm/i915: Replace global breadcrumbs with per-context
interrupt tracking")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence.c | 1 +
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 78 +++--
d
Move the duplicated code within dma-fence.c into the header for wider
reuse. In the process apply a small micro-optimisation to only prune the
fence->cb_list once rather than use list_del on every entry.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/dma-buf/Makef
gacy_dev_reinit is there already too,
> plus it fits perfectly into Dave's work of making DRIVER_LEGACY code
> compile-time optional.
>
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
___
dr
Quoting Daniel Vetter (2019-05-02 08:27:27)
> +static int drm_legacy_setup(struct drm_device * dev)
> +{
> + int ret;
> +
> + if (dev->driver->firstopen &&
> + drm_core_check_feature(dev, DRIVER_LEGACY)) {
> + ret = dev->driver->firstopen(dev);
> +
Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> From: Daniel Drake
>
> On many (all?) the Gemini Lake systems we work with, there is frequent
> momentary graphical corruption at the top of the screen, and it seems
> that disabling framebuffer compression can avoid this.
>
> The ticket was
Quoting Daniel Vetter (2019-04-23 09:21:16)
> On Fri, Apr 19, 2019 at 07:19:04PM +0100, Chris Wilson wrote:
> > sync_dump() is an unused, unexported, function that adds 64k to the
> > kernel image and doesn't even provide locking around the global array it
> > uses.
> >
198 --198
sync_dump_buf 65536 - -65536
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
---
drivers/dma-buf/sync_debug.c | 26 --
drivers/dma-buf/sync_debug.h | 1 -
2 files changed, 27
Quoting Thomas Zimmermann (2019-04-18 08:29:39)
> Hi
>
> Am 18.04.19 um 00:16 schrieb Kuehling, Felix:
> > Adding dri-devel
> >
> > On 2019-04-17 6:15 p.m., Yang, Philip wrote:
> >> After patch "drm: Use the same mmap-range offset and size for GEM and
> >> TTM", application failed to create bo
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Gwan-gyeong Mun (2019-04-12 15:06:17)
> After suspend/resume process, hotplug detection is handled by
> i915_hpd_poll_init_work() workqueue. While intel_hdmi_detect() or
> intel_dp_detect() are called, intel_hdmi_set_edid() or intel_dp_set_edid()
> only update an internal detect_edid
Quoting Chris Wilson (2019-03-25 08:07:33)
> When one of the array of fences is signaled, propagate its errors to the
> parent fence-array (keeping the first error to be raised).
>
> v2: Opencode cmpxchg_local to avoid compiler freakout.
>
> Signed-off-by: Chris Wilson
> C
Quoting Janusz Krzysztofik (2019-04-05 13:13:31)
> From: Janusz Krzysztofik
>
> If there are active users of a device during driver unbind, the driver
> now panics on non-empty list of free cachelines.
This panic is there to say that fini is being called with active
contexts, that it is being
Quoting Janusz Krzysztofik (2019-04-05 09:11:54)
> On Fri, 2019-04-05 at 08:41 +0100, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-04-05 08:26:57)
> > > From: Janusz Krzysztofik
> > >
> > > The driver does not currently support unbinding from
Quoting Janusz Krzysztofik (2019-04-05 08:26:57)
> From: Janusz Krzysztofik
>
> The driver does not currently support unbinding from a device which is
> in use. Since open file descriptors may still be pointing into kernel
> memory where the device structures used to be, entirely correct kernel
Quoting Janusz Krzysztofik (2019-04-04 11:50:14)
> On Thu, 2019-04-04 at 11:43 +0100, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-04-04 11:40:24)
> > > On Thu, 2019-04-04 at 11:28 +0100, Chris Wilson wrote:
> > > > Quoting Janusz Krzysztofik (2019-
Quoting Janusz Krzysztofik (2019-04-04 11:40:24)
> On Thu, 2019-04-04 at 11:28 +0100, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-04-04 11:24:45)
> > > From: Janusz Krzysztofik
> > >
> > > In case the driver gets unbound while a device is open, ke
Quoting Janusz Krzysztofik (2019-04-04 11:24:45)
> From: Janusz Krzysztofik
>
> In case the driver gets unbound while a device is open, kernel panic
> may be forced if a list of allocated context IDs is not empty.
>
> When a device is open, the list may happen to be not empty because a
>
Quoting Daniel Vetter (2019-04-01 14:06:48)
> On Mon, Apr 1, 2019 at 9:47 AM Rob Herring wrote:
> > +{
> > + int i, ret = 0;
> > + struct drm_gem_object *obj;
> > +
> > + spin_lock(>table_lock);
> > +
> > + for (i = 0; i < count; i++) {
> > + /* Check if we
Quoting Mika Kuoppala (2019-03-26 09:30:57)
> Dan Carpenter writes:
>
> > The live_context() function returns error pointers. It never returns
> > NULL.
> >
> > Fixes: 9c1477e83e62 ("drm/i915/selftests: Exercise adding requests to a
> > full GGTT")
> > Signed-off-by: Dan Carpenter
>
>
Quoting Dan Carpenter (2019-03-25 09:23:49)
> If gem_context_register() fails then "ctx" is a valid pointer, not an
> error pointer. We should just return "err".
>
> Fixes: 3aa9945a528e ("drm/i915: Separate GEM context construction and
> registration to userspace")
> Signed-off-by: Dan
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
v2: Opencode cmpxchg_local to avoid compiler freakout.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
---
drivers/dma-buf/dma-fence-array.c
Same as for the individual fences, we want to report the actual status
of the fence when queried.
Reported-by: Petri Latvala
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Petri Latvala
---
drivers/dma-buf/sync_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
501 - 600 of 3670 matches
Mail list logo
