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
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:
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
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
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
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 poi
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
NGS(), 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 overflow in the
BITS
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
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 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
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
> >
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 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 (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 put
mb 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-devel@l
quot;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
> ---
>
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
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
gned-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
___
d
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 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
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
the
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)")
Signed-off
g 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 this machine.
>
> Changes since v2:
> *
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.
>
>
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
itly 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
> >
> > Reviewed-by: Nick Desaulnier
Quoting Daniel Vetter (2019-01-22 09:11:53)
> On Tue, Jan 22, 2019 at 10:06 AM Chris Wilson
> wrote:
> >
> > Quoting Koenig, Christian (2019-01-22 08:49:30)
> > > Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > > > Rather than every backend an
Quoting Koenig, Christian (2019-01-22 08:49:30)
> Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > 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 tracing in
ique dma_fence_ops, and
preferring to have descriptors for the whole fence context). strings do
not pack as well into the ftrace ringbuffer and we would prefer to
reduce the amount of indirect callbacks required for frequent tracepoint
emission.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko
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
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.
> >
("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 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
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
>
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 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
Quoting Kuo-Hsin Yang (2018-12-14 10:09:11)
> On Fri, Dec 14, 2018 at 5:51 PM Chris Wilson wrote:
> >
> > Quoting Kuo-Hsin Yang (2018-12-14 09:33:19)
> > > On Fri, Dec 14, 2018 at 4:59 PM Chris Wilson
> > > wrote:
> > > >
> > > >
&
Quoting Kuo-Hsin Yang (2018-12-14 09:33:19)
> On Fri, Dec 14, 2018 at 4:59 PM Chris Wilson wrote:
> >
> >
> > Do you have a driver in mind (msm?) to demonstrate the use case?
>
> On Samsung Chromebook Plus, the drm/rockchip driver may call
> rockchip_gem_get_page
Quoting Kuo-Hsin Yang (2018-12-14 08:41:35)
> The gem drivers use shmemfs to allocate backing storage for gem objects.
> These shmemfs pages can be pinned by shmem_read_mapping_page_gfp(). Mark
> these pinned pages as unevictable to speed up vmscan. See also similar
> patch on i915 driver [1].
Quoting Koenig, Christian (2018-12-13 12:11:10)
> Am 13.12.18 um 12:37 schrieb Chris Wilson:
> > Quoting Chunming Zhou (2018-12-11 10:34:45)
> >> From: Christian König
> >>
> >> Implement finding the right timeline point in drm_syncobj_find_fence.
> &g
Quoting Chunming Zhou (2018-12-11 10:34:45)
> From: Christian König
>
> Implement finding the right timeline point in drm_syncobj_find_fence.
>
> v2: return -EINVAL when the point is not submitted yet.
> v3: fix reference counting bug, add flags handling as well
>
> Signed-off-by: Christian
Quoting Chunming Zhou (2018-12-11 10:34:40)
> From: Christian König
>
> Lockless container implementation similar to a dma_fence_array, but with
> only two elements per node and automatic garbage collection.
>
> v2: properly document dma_fence_chain_for_each, add
> dma_fence_chain_find_seqno,
Quoting Chris Wilson (2018-12-07 12:22:40)
> Many errs of the form:
> drivers/gpu/drm/i915/selftests/intel_hangcheck.c: In function
> ‘__igt_reset_evict_vma’:
> ./include/linux/kern_levels.h:5:18: error: format ‘%x’ expects argument of
> type ‘unsigned int’, but argum
Wait, there
t;)
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Chunming Zhou
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/d
Quoting jgli...@redhat.com (2018-12-06 15:47:04)
> From: Jérôme Glisse
>
> The debugfs take reference on fence without dropping them. Also the
> rcu section are not well balance. Fix all that ...
Wouldn't the code be a lot simpler (and a consistent snapshot) if it used
Quoting Michel Dänzer (2018-12-06 09:21:40)
> On 2018-12-06 10:12 a.m., Chris Wilson wrote:
> > Quoting Zhang, Jerry(Junwei) (2018-12-06 02:40:42)
> >> On 12/6/18 12:56 AM, Michel Dänzer wrote:
> >>> From: Michel Dänzer
> >>>
> >>> The foll
Quoting Zhang, Jerry(Junwei) (2018-12-06 02:40:42)
> On 12/6/18 12:56 AM, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > The following cases are possible for pr_debug():
> >
> > 1. CONFIG_DYNAMIC_DEBUG disabled
> > a) DEBUG not defined: pr_debug() translates to no_printk(...), i.e.
> >
Quoting Chris Wilson (2018-12-04 12:52:15)
> Quoting Christian König (2018-12-04 11:59:39)
> > -static inline bool __dma_fence_is_later(u32 f1, u32 f2)
> > +static inline bool __dma_fence_is_later(u64 f1, u64 f2)
> > {
> > - return (int)(f1 - f2) > 0;
>
Quoting Christian König (2018-12-04 11:59:39)
> -static inline bool __dma_fence_is_later(u32 f1, u32 f2)
> +static inline bool __dma_fence_is_later(u64 f1, u64 f2)
> {
> - return (int)(f1 - f2) > 0;
> + /* This is for backward compatibility with drivers which can only
> handle
> +
> > Besides some mechanical tree wide changes Chris Wilson is the sole
> > author of these files with Intel holding the copyright.
> >
> > Intel's legal team have given permission to change the license according
> > to Joonas Lahtinen.
> >
> > v2: expan
Quoting Christian König (2018-12-03 16:12:14)
> Am 03.12.18 um 17:08 schrieb Eric Anholt:
> > Christian König writes:
> >
> >> Extract of useful code from the timeline work. This provides a function
> >> to return a stub or dummy fence which is always signaled.
> >>
> >> Signed-off-by: Christian
Quoting Eric Anholt (2018-12-03 16:08:40)
> Christian König writes:
>
> > Extract of useful code from the timeline work. This provides a function
> > to return a stub or dummy fence which is always signaled.
> >
> > Signed-off-by: Christian König
> > ---
> > drivers/dma-buf/dma-fence.c | 36
Quoting Alex Deucher (2018-12-03 15:53:21)
> On Mon, Dec 3, 2018 at 8:40 AM Christian König
> wrote:
> >
> > Am 03.12.18 um 14:33 schrieb Chunming Zhou:
> > > The series is Reviewed-by: Chunming Zhou
> > >
> > > for patch#2, please remove my Signed-off-by, it's new when using stub
> > > from
Quoting Christian König (2018-12-03 13:07:58)
> Extract of useful code from the timeline work. Let's use just a single
> stub fence instance instead of allocating a new one all the time.
>
> Signed-off-by: Chunming Zhou
> Signed-off-by: Christian König
Reviewed-by: Chris
Quoting Christian König (2018-12-03 13:07:57)
> Extract of useful code from the timeline work. This provides a function
> to return a stub or dummy fence which is always signaled.
>
> Signed-off-by: Christian König
Reviewed-by: Chris Wi
Quoting Christian König (2018-11-28 14:50:12)
> +/**
> + * dma_fence_chain_for_each - iterate over all fences in chain
> + * @fence: starting point as well as current fence
> + *
> + * Iterate over all fences in the chain. We keep a reference to the current
> + * fence while inside the loop which
Quoting Stanislav Lisovskiy (2018-11-28 13:52:10)
> Currently kernel might allocate different connector ids
> for the same outputs in case of DP MST, which seems to
> confuse userspace. There are can be different connector
> ids in the list, which could be assigned to the same
> output, while
Quoting Daniel Vetter (2018-11-27 17:28:43)
> On Tue, Nov 27, 2018 at 5:50 PM Chris Wilson wrote:
> >
> > Quoting Daniel Vetter (2018-11-27 07:49:18)
> > > On Thu, Nov 22, 2018 at 05:51:06PM +0100, Daniel Vetter wrote:
> > > > This is a similar idea to th
Quoting Daniel Vetter (2018-11-27 07:49:18)
> On Thu, Nov 22, 2018 at 05:51:06PM +0100, 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.
>
Quoting Monk Liu (2018-11-27 03:10:34)
> v2:
> amend description:
> for RB tree traveler we don't need to travel to
> the bottom level if already found the equal size node,
> thus the search performance can get improved.
>
> v3:
> split "<=" to "<" case and "==" case
>
> Tested-by: Rex Zhu
>
Quoting Liu, Monk (2018-11-23 09:11:02)
> What do you mean the first in the chain ? and also can you explain the "
> perfect match." ? thanks
>
> Assume there is couple nodes equal to the size you requested, without this
> patch it will traveler to the bottom level of the RB tree and gives you
Quoting Liu, Monk (2018-11-23 08:02:11)
>
>
> -Original Message-
> From: amd-gfx On Behalf Of Monk Liu
> Sent: Thursday, November 22, 2018 8:33 PM
> To: amd-...@lists.freedesktop.org
> Cc: Liu, Monk
> Subject: [PATCH] drm: should break if already get the best size
>
> Signed-off-by:
Quoting Daniel Vetter (2018-11-22 16:51:04)
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
Most callers could handle the failure correctly. It looks like the
Quoting Uma Shankar (2018-11-20 14:22:10)
> @@ -1457,6 +1480,18 @@ int drm_mode_create_colorspace_property(struct
> drm_connector *connector)
> return -ENOMEM;
>
> dev->mode_config.hdmi_colorspace_property = prop;
> + } else if
d at (133146): []
__do_softirq+0x365/0x47c
[5.596748] softirqs last disabled at (133139): []
irq_exit+0x119/0x120
[5.596749] ---[ end trace eaee508abfebccdc ]---
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108709
Signed-off-by: Chris Wilson
Cc: Alex Deucher
---
drivers/gpu/dr
Quoting Ville Syrjälä (2018-11-13 19:13:40)
> On Tue, Nov 13, 2018 at 06:49:38PM +0000, Chris Wilson wrote:
> > Quoting Stanislav Lisovskiy (2018-11-13 07:45:02)
> > > @@ -408,6 +424,9 @@ void sna_video_textured_setup(struct sna *sna,
> > > ScreenPtr screen)
> > &
Quoting Stanislav Lisovskiy (2018-11-13 07:45:02)
> @@ -408,6 +424,9 @@ void sna_video_textured_setup(struct sna *sna, ScreenPtr
> screen)
> } else if (sna->kgem.gen < 040) {
> adaptor->nImages = ARRAY_SIZE(gen3_Images);
> adaptor->pImages = (XvImageRec
Quoting Stanislav Lisovskiy (2018-11-13 14:31:38)
> Currently whenever we attempt to recalculate
> watermarks, we assign dirty_pipes to zero,
> then compare current wm results to the recalculated
> one and if they changed we set correspondent dirty_pipes
> bit again.
> This can lead to situation,
We need to include the revert of commit 783195ec1cad ("drm/syncobj:
disable the timeline UAPI for now v2") along with undoing the change to
drm/i915.
Fixes: 131280a162e7 ("drm: Revert syncobj timeline changes.")
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vett
Quoting Christian König (2018-11-12 10:16:01)
> Am 09.11.18 um 23:26 schrieb Eric Anholt:
>
> Eric Anholt writes:
>
>
> [ Unknown signature status ]
> zhoucm1 writes:
>
>
> On 2018年11月09日 00:52, Christian König wrote:
>
> Am 08.11.18 um 17:07
Quoting Christian König (2018-10-19 10:27:11)
> From: Christian König
>
> Still contains some bugs.
>
> This reverts commit 48197bc564c7a1888c86024a1ba4f956e0ec2300.
>
> Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=108490
> Signed-off-by: Christian König
The code for the old style of
Quoting Colin King (2018-11-07 10:22:11)
> From: Colin Ian King
>
> Trivial fix to spelling mistake in DRM_INFO message
>
> Signed-off-by: Colin Ian King
Thank you for the spelling correction, applied.
-Chris
___
dri-devel mailing list
If we fail to register all the initial CRTCs and connectors, report that
failure back to the caller.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_drv.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
Quoting kbuild test robot (2018-10-26 16:55:25)
> Hi Emil,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on sof-driver-fuweitax/master]
> [also build test ERROR on v4.19 next-20181019]
> [if your patch is applied to the wrong git tree, please drop us a note to
Quoting Daniel Vetter (2018-11-02 13:25:42)
> This essentially undoes
>
> commit 39868bd7668bd47308b1dfd97c212757caee764f
> Author: Chris Wilson
> Date: Tue Oct 29 08:55:58 2013 +
>
> drm: Compact booleans within struct drm_file
>
> We do lockless acces
Quoting Robert Foss (2018-11-02 12:13:13)
> If dma_fence_wait fails to wait for a supplied in-fence in
> msm_ioctl_gem_submit, make sure we release that in-fence.
>
> Also remove this dma_fence_put() from the 'out' label.
>
> Signed-off-by: Robert Foss
Reviewed-by:
Quoting Robert Foss (2018-11-01 16:12:28)
> If dma_fence_wait fails to wait for a supplied in-fence in
> msm_ioctl_gem_submit, make sure we release that in-fence.
>
> Also remove this dma_fence_put() from the 'out' label.
>
> Signed-off-by: Robert Foss
> ---
>
Quoting zhoucm1 (2018-11-01 08:53:02)
>
>
> On 2018年10月31日 20:07, Chris Wilson wrote:
> > drivers/gpu/drm/drm_syncobj.c:181:6: warning: no previous prototype for
> > ‘drm_syncobj_add_callback’ [-Wmissing-prototypes]
> > drivers/gpu/drm/drm_syncobj.c:190:6: war
/drm_syncobj.c:181:13: warning: ‘drm_syncobj_add_callback’
defined but not used [-Wunused-function]
so remove the unused drm_syncobj_add_callback() entirely.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git
Quoting Jonathan Gray (2018-10-31 00:56:12)
> Chris Wilson said Intel is willing to change the license of these files
> to MIT.
>
> Signed-off-by: Jonathan Gray
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing li
fer.c.
>
> Signed-off-by: Jonathan Gray
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Emil Velikov (2018-10-29 12:00:17)
> On Fri, 26 Oct 2018 at 15:40, Chris Wilson wrote:
> >
> > Quoting Daniel Vetter (2018-10-26 14:40:36)
> > > On Fri, Oct 26, 2018 at 01:06:47PM +0100, Emil Velikov wrote:
> > > > From: Emil Velikov
> > &g
Quoting Daniel Vetter (2018-10-26 14:40:36)
> On Fri, Oct 26, 2018 at 01:06:47PM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > VGEM doesn't do anything modeset specific, so in a way exposing a
> > primary node is 'wrong'. At the same time, we extensively use if for
> > creating dumb
010 DS: ES: CR0: 80050033
<4> [109.613360] CR2: 7f9c9fcb8000 CR3: 0002247d4005 CR4:
000606e0
Fixes: 27836b641c1b ("dma-buf: remove shared fence staging in reservation
object")
Testcase: igt/gem_busy/close-race
Signed-off-by: Chris Wilson
Cc: Ch
Quoting Chris Wilson (2018-10-25 21:20:21)
> Quoting Chris Wilson (2018-10-25 21:15:17)
> > Quoting Christian König (2018-10-04 14:12:43)
> > > No need for that any more. Just replace the list when there isn't enough
> > > room any more for the additional fence.
>
Quoting Chris Wilson (2018-10-25 21:15:17)
> Quoting Christian König (2018-10-04 14:12:43)
> > No need for that any more. Just replace the list when there isn't enough
> > room any more for the additional fence.
>
> Just a heads up. After this series landed, we started hitti
Quoting Christian König (2018-10-04 14:12:43)
> No need for that any more. Just replace the list when there isn't enough
> room any more for the additional fence.
Just a heads up. After this series landed, we started hitting a
use-after-free when iterating the shared list.
<4> [109.613162]
yncobj_wait and ./deqp-vk -n dEQP-VK.*semaphore* with
> lock debug kernel options enabled.
>
> Signed-off-by: Chunming Zhou
> Cc: Maarten Lankhorst
> Cc: intel-...@lists.freedesktop.org
> Cc: Christian König
> Cc: Chris Wilson
> CC: Julia Lawall
> ---
> - r
Give this a nice summary,
drm/syncobj: Avoid kmalloc(GFP_KERNEL) under spinlock
Quoting Chunming Zhou (2018-10-25 11:21:05)
> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
> 389 but uses GFP_KERNEL
>
>
Quoting Daniel Vetter (2018-10-19 09:43:11)
> We recently bikeshedded this to a different flavour, but forgot to
> update the recommendations.
>
> Cc: Chris Wilson
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
> ---
> Documentation/gpu/d
Quoting zhoucm1 (2018-10-23 10:09:01)
>
>
> On 2018年10月23日 17:01, Chris Wilson wrote:
> > Quoting Chunming Zhou (2018-10-23 08:57:54)
> >> v2:
> >> add a mutex between sync_cb execution and free.
> >> v3:
> >> clearly separating
v5:
> fix a corner case
>
> Tested by syncobj_basic and syncobj_wait of igt.
>
> Signed-off-by: Chunming Zhou
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Christian König
> Cc: intel-...@lists.freedesktop.org
> Reviewed-by: Chr
Quoting zhoucm1 (2018-10-23 09:00:26)
>
>
> On 2018年10月23日 15:51, Chris Wilson wrote:
> > Quoting Chunming Zhou (2018-10-23 02:50:08)
> >> v2:
> >> add a mutex between sync_cb execution and free.
> >> v3:
> >> clearly separating
gt; Tested by syncobj_basic and syncobj_wait of igt.
>
> Signed-off-by: Chunming Zhou
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Christian König
> ---
> drivers/gpu/drm/drm_syncobj.c | 51 ++-
> include/drm/drm_syncobj.h | 8 --
Quoting Mamta Shukla (2018-10-20 18:49:26)
> Use DRM_DEV_INFO/ERROR/WARN instead of dev_info/err/debug to generate
> drm-formatted specific log messages so that it will be easy to
> differentiate in case of multiple instances of driver.
Do you not think this is a bit backwards? Both dev_* and
Quoting Jonathan Gray (2018-10-21 09:57:32)
> Commit b24413180f5600bcb3bb70fbed5cf186b60864bd added
> "SPDX-License-Identifier: GPL-2.0" to files which previously had no
> license, change this to MIT for the tracing header matching the license
> text of most of the other core drm files.
I'm not
Quoting Chunming Zhou (2018-10-22 10:08:59)
> v2:
> add a mutex between sync_cb execution and free.
> v3:
> clearly separating the roles for pt_lock and cb_mutex (Chris)
>
> Signed-off-by: Chunming Zhou
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Christian Köni
Quoting Chunming Zhou (2018-10-21 12:14:24)
> v2:
> add a mutex between sync_cb execution and free.
The result would appear to be that syncobj->lock is relegated to
protecting the pt_list and the mutex would only be needed for the
syncobj->cb_list.
The patch looks correct for resolving the
601 - 700 of 3670 matches
Mail list logo
