d.
> > >
> > > Explicitly disable the warning like commit 46e2068081e9 ("drm/i915:
> > > Disable some extra clang warnings").
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/220
> > > Signed-off-by: Nathan Chancellor
>
Quoting Michael Sartain (2019-01-29 01:52:12)
> On Mon, Jan 21, 2019, at 4:20 PM, Chris Wilson wrote:
> > Rather than every backend and GPU driver reinventing the same wheel for
> > user level debugging of HW execution, the common dma-fence framework
> > should include the t
Quoting Lyude Paul (2019-01-28 20:56:01)
> When resuming, we check whether or not any previously connected
> MST topologies are still present and if so, attempt to resume them. If
> this fails, we disable said MST topologies and fire off a hotplug event
> so that userspace knows to reprobe.
>
> Ho
ce while we're resuming, while also preventing us from
> actually processing any hotplug events we receive until it's safe.
>
> This fixes the wakeref leak observed on the T480s and as such, also
> fixes suspend/resume with MST topologies connected on
fence array.
v4: Drop the fence array ref after assigning to reservation_object
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107341
Testcase: igt/amd_prime/amd-to-i915
References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported
bo's. (v5)")
Signe
CI complains that the exhaustive test of trying every size up to the
limit is too slow, so add a simple test that tries to submit one
extreme batch buffer and check all the relocations land.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
Signed-off-by: Chris Wilson
---
tests/i915
Quoting Daniel Vetter (2019-02-13 09:50:55)
> On Tue, Feb 12, 2019 at 10:32:31PM +0100, Mario Kleiner wrote:
> > I think all kms drivers try to call drm_crtc_handle_vblank() at start
> > of vblank to give Mesa the most time for frontbuffer rendering for
> > classic X. But vblank events are also use
CI complains that the exhaustive test of trying every size up to the
limit is too slow, so add a simple test that tries to submit one
extreme batch buffer and check all the relocations land.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
Signed-off-by: Chris Wilson
---
Continue
Quoting Nick Desaulniers (2018-10-25 23:20:58)
> On Thu, Oct 25, 2018 at 12:36 PM Nathan Chancellor
> wrote:
> >
> > This warning is disabled by default in scripts/Makefile.extrawarn when
> > W= is not provided but this Makefile adds -Wall after this warning is
> > disabled so it shows up in the b
pages as unevictable to avoid the premature oom-killer
> invocation. See also similar patch on i915 driver [1].
>
> [1]:
> https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-ch...@chris-wilson.co.uk
>
> Signed-off-by: Kuo-Hsin Yang
&
Quoting Bin Yang (2018-12-20 08:01:35)
> Normally, i915_request_alloc() and i915_request_add() will be called
> in sequence with drm.struct_mutex locked. But in
> intel_vgpu_create_workload(), it will pre-allocate the request and
> call i915_request_add() in the workload thread for performance
> op
Quoting Brajeswar Ghosh (2018-12-25 13:23:40)
> Remove i915_scheduler.h which is included more than once
>
> Signed-off-by: Brajeswar Ghosh
Thanks for the patch, pushed to dinq.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://
("drm: Handle properties in the core for atomic drivers")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: # v4.14+
---
drivers/gpu/drm/drm_mode_object.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/d
Quoting Maarten Lankhorst (2019-01-03 09:03:27)
> Op 30-12-2018 om 13:28 schreef Chris Wilson:
> > Delay the drm_modeset_acquire_init() until after we check for an
> > allocation failure so that we can return immediately upon error without
> > having to unwind.
> >
gt; [1]:
> https://patchwork.freedesktop.org/patch/msgid/20181106132324.17390-1-ch...@chris-wilson.co.uk
>
> Signed-off-by: Kuo-Hsin Yang
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Reviewed-by: Chris Wilson
No objections, so pushed to drm-misc-next. Let the screaming begin.
Thanks for the patc
")
> Signed-off-by: Colin Ian King
I hope already fixed by
commit 2a4a2754039594c60b58b02b6781428a85f6d745
Author: Chris Wilson
Date: Fri Feb 15 19:50:10 2019 +
drm/i915/selftests: Always free spinner on __sseu_prepare error
Thanks,
-Chris
__
Quoting Chengguang Xu (2019-02-21 02:08:19)
> unlikely has already included in IS_ERR(), so just
> remove redundant likely/unlikely annotation.
>
> Signed-off-by: Chengguang Xu
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing li
Quoting Chris Wilson (2019-02-21 12:03:18)
> Quoting Chengguang Xu (2019-02-21 02:08:19)
> > unlikely has already included in IS_ERR(), so just
> > remove redundant likely/unlikely annotation.
> >
> > Signed-off-by: Chengguang Xu
> Reviewed-by: Chris Wilson
An
9190d02 ("drm/vgem: Enable dmabuf import interfaces")
Cc: Chris Wilson
Cc: Laura Abbott
Cc: Daniel Vetter
Sadly I reviewed it so I'm still culpable, but the fix is correct as the
put purposely frees it on error.
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eric Biggers
dd dumb operations")
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eric Biggers
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-de
Quoting Daniel Vetter (2017-08-07 10:28:58)
> On Fri, Aug 04, 2017 at 09:23:28AM +0100, Chris Wilson wrote:
> > After an event is sent, we try to copy it into the user buffer of the
> > first waiter in drm_read() and if the user buffer doesn't have enough
> > room we
Quoting Chris Wilson (2019-02-27 10:17:15)
> Quoting Daniel Vetter (2017-08-07 10:28:58)
> > On Fri, Aug 04, 2017 at 09:23:28AM +0100, Chris Wilson wrote:
> > > After an event is sent, we try to copy it into the user buffer of the
> > > first waiter in drm_read() and
Quoting Daniel Vetter (2019-02-28 09:49:51)
> On Thu, Feb 28, 2019 at 5:30 AM Dave Airlie wrote:
> >
> > I merged some fixes into drm-fixes, pushed it out, then saw tip
> > breaking, but I'm needed elsewhere, so if anyone can fix tip up or
> > tell me why I got a super messy commit, I'll owe you.
Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38)
> On 2019-02-12 17:28:57 [+0100], To linux-ker...@vger.kernel.org wrote:
> > The timer is initialized with TIMER_IRQSAFE flag. It does look like the
> > timer callback requires this flag at all. Its sole purpose is to ensure
> > synchronisatio
Quoting Thomas Gleixner (2019-02-28 10:09:26)
> On Thu, 28 Feb 2019, Chris Wilson wrote:
>
> > Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38)
> > > On 2019-02-12 17:28:57 [+0100], To linux-ker...@vger.kernel.org wrote:
> > > > The timer is initialized
Bad EDID are a fact of life when dealing with random monitors. We only
spam the logs when debugging is enabled, but we only need to raise
notice and not set off the warning bells.
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
---
drivers/gpu/drm/drm_edid.c | 11 +--
1 file changed
Quoting Alex Deucher (2019-02-28 17:25:41)
> On Thu, Feb 28, 2019 at 4:54 AM Chris Wilson wrote:
> >
> > Quoting Daniel Vetter (2019-02-28 09:49:51)
> > > On Thu, Feb 28, 2019 at 5:30 AM Dave Airlie wrote:
> > > >
> > > > I merged some f
it kills BITS_TO_LONGS(), even though I do not see why
the bitmap_[z]alloc and bitmap_free are not inlines...
And for this is not the overflow protection of kcalloc silly? We start
with a large value, factorise it, then check that the two factors do not
overflow? If it were to overflow, it would overfl
Quoting Andy Shevchenko (2019-03-04 09:29:07)
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns pointer of bitmap type instead of opaque void *.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Chris Wi
Quoting Andy Shevchenko (2019-03-04 09:54:46)
> On Mon, Mar 04, 2019 at 09:41:34AM +0000, Chris Wilson wrote:
> > Quoting Andy Shevchenko (2019-03-04 09:29:08)
> > > Switch to bitmap_zalloc() to show clearly what we are allocating.
> > > Besides that it returns pointe
Quoting Andy Shevchenko (2019-03-05 10:20:31)
> On Tue, Mar 05, 2019 at 11:28:36AM +0200, Joonas Lahtinen wrote:
> > I take it that both instances are supposed to call bitmap_zalloc?
> >
> > If you can send a v2 that compiles, I can merge it after it passes the
> > CI.
>
> v2 had been sent yester
Quoting Nathan Chancellor (2019-03-08 01:20:24)
> When building with -Wsometimes-uninitialized, Clang warns:
>
> drivers/gpu/drm/i915/i915_request.c:1032:6: warning: variable 'this_cpu'
> is used uninitialized whenever '&&' condition is false
> [-Wsometimes-uninitialized]
>
> time_after expands t
Quoting Kangjie Lu (2019-03-09 04:24:50)
> If the allocation fails, return false to avoid potential
> NULL pointer dereference
No. If we fail to allocate c->tmp, we do uncached reads instead.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.
i is pure cleanup. So for the time being, best to
leave intel_uc_fini() here.
> + mutex_unlock(&dev_priv->drm.struct_mutex);
> +
> + i915_gem_drain_freed_objects(dev_priv);
> +}
> +
> +void i915_gem_fini(struct drm_i915_private *dev_priv)
> +{
> + mutex_lock(&dev_priv->drm.struct_mutex);
> i915_gem_contexts_fini(dev_priv);
> i915_gem_fini_scratch(dev_priv);
> mutex_unlock(&dev_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 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 ("drm/i9
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 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
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/0x380
&
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
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
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
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
dri-devel@lists.fre
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 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
>
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
> PANFROST_BO_NOM
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 sure
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
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
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 use-a
Quoting Chris Wilson (2019-03-04 09:43:43)
> Quoting Andy Shevchenko (2019-03-04 09:29:07)
> > Switch to bitmap_zalloc() to show clearly what we are allocating.
> > Besides that it returns pointer of bitmap type instead of opaque void *.
> >
> > Signed-off-by: And
When one of the array of fences is signaled, propagate its errors to the
parent fence-array (keeping the first error to be raised).
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
---
drivers/dma-buf/dma-fence-array.c | 4
1 file changed, 4 insertions(+)
diff --git a
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
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
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 Carpenter
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
>
> Reviewe
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(&filp->table_lock);
> > +
> > + for (i = 0; i < count; i++) {
> > + /* Check if
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
> context
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: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-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 st
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
> @@ -2388,19
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.
-C
s to see extern header churn.
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
--- a
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
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
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
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 query for t
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 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 drm_cfl
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
dri-devel@lists.freedesktop.org
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 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 wo
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-bloc
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
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:
ime_export 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 o
ime_export 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 mo
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
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 circumlocution,
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 ex
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 ST
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 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/
\
> +(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
nical,
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
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
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.
> > >
>
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 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,
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[] = "huge=ne
ps->reconfigure(fc))
> + 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 reconfig
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 a/drivers/g
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 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 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
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
201 - 300 of 3785 matches
Mail list logo
