Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

Quoting Chris Wilson (2017-10-24 17:17:09) > Quoting Kees Cook (2017-10-24 16:13:44) > > In preparation for unconditionally passing the struct timer_list pointer to > > all timer callbacks, switch to using the new timer_setup() and from_timer() > > to pass the timer pointer ex

Re: [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

ux.intel.com> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Rodrigo Vivi <rodrigo.v...@intel.com> > Cc: David Airlie <airl...@linux.ie> > Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc:

Re: [PATCH] drm: Hold idr_mutex for _drm_lease_revoke

Quoting Chris Wilson (2017-10-19 11:53:44) > _drm_lease_revoke() requires it callers to hold the idr_mutex, but its > only caller did not. Every device release would then trigger: > > WARNING: CPU: 7 PID: 4169 at drivers/gpu/drm/drm_lease.c:313 > _drm_lease_revoke+0x12c/0x140 &g

[PATCH] drm: Hold idr_mutex for _drm_lease_revoke

90 90 90 90 90 90 0f Fixes: 801d74c2fe00 ("drm: Add drm_object lease infrastructure [v5]") Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Keith Packard <kei...@keithp.com> Cc: Sean Paul <seanp...@chromium.org> Cc: Daniel Vetter <daniel.vet...@ffwll.ch

Re: [PATCH] dma-fence: remove duplicate word in comment

Quoting Frank Binns (2017-10-18 14:30:23) You mean it's not markdown for making it double-height bold? > Signed-off-by: Frank Binns <frank.bi...@imgtec.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris ___ dri-devel m

Re: [Intel-gfx] [PATCH i-g-t 3/7] lib: Fix compilation on non-x86

Quoting Thierry Reding (2017-10-12 14:29:39) > diff --git a/lib/igt_x86.h b/lib/igt_x86.h > index d6dcfa108331..27b7f0fd5837 100644 > --- a/lib/igt_x86.h > +++ b/lib/igt_x86.h > @@ -40,7 +40,7 @@ > #define AVX0x80 > #define AVX2 0x100 > > -#if defined(__x86_64__) > +#if

Re: [PATCH v2 1/3] drm: Extract drm_debug.[hc]

Quoting Haneen Mohammed (2017-10-12 03:32:53) > diff --git a/drivers/gpu/drm/drm_debug.c b/drivers/gpu/drm/drm_debug.c > new file mode 100644 > index 000..a79593f > --- /dev/null > +++ b/drivers/gpu/drm/drm_debug.c > @@ -0,0 +1,75 @@ > +/* > + * Copyright 2001 VA Linux Systems, Inc.,

Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

Quoting Ville Syrjälä (2017-10-09 17:18:17) > On Mon, Sep 25, 2017 at 08:19:12PM +0100, Chris Wilson wrote: > > Quoting ville.syrj...@linux.intel.com (2016-04-01 19:48:50) > > > From: Ville Syrjälä <ville.syrj...@linux.intel.com> > > > > > > Eliminate

Re: [PATCH v2] sync_file: Return consistent status in SYNC_IOC_FILE_INFO

> Tested-by: Vamsidhar Reddy Gaddam <vamsidhar.gad...@arm.com> > Signed-off-by: John Einar Reitan <john.rei...@arm.com> > Cc: Sumit Semwal <sumit.sem...@linaro.org> > Cc: Gustavo Padovan <gust...@padovan.org> > Cc: dri-devel@lists.freede

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

Quoting Harsha Sharma (2017-10-08 15:04:07) > @@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev, > ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8; > ifbdev->fb = fb; > > - drm_framebuffer_reference(>fb->base); > +

Re: [PATCH] drm/i915/selftests: fix check for intel IOMMU

ettled for something that appeared good enough (for the small selection of configs I tested). Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] sync_file: Return consistent status in SYNC_IOC_FILE_INFO

nc_file > *sync_file, > * sync_fence_info and return the actual number of fences on > * info->num_fences. > */ > - if (!info.num_fences) > + if (!info.num_fences) { > + fences_status = dma_fence_is_signaled(sync_file->fence); Personally I would hav

Re: [pull] amdgpu dc drm-next-4.15-dc

Quoting Alex Deucher (2017-09-27 02:36:07) > Hi Dave, > > Initial pull request for DC support. We've completed a substantial amount of > the cleanup and restructuring in our TODO. There are a few additional > cleanups that we are continuing to work on, but I don't think there are any >

Re: [PATCH] drm/gem: use new idr deletion interface to cleanup drm_gem_handle_delete()

hen hooked up to the old private data. See commit f6cd7daecff558fab2c45d15283d3e52f688342d Author: Chris Wilson <ch...@chris-wilson.co.uk> Date: Fri Apr 15 12:55:08 2016 +0100 drm: Release driver references to handle before making it available again -Chris ___

Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

t; > v2: Store dotclock in adjusted_mode instead of the final mode > > Cc: dri-devel@lists.freedesktop.org > Cc: Rob Kramer <r...@solution-space.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com> Reviewed-by: Chri

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()

der") > References: > https://lists.freedesktop.org/archives/dri-devel/2016-April/104142.html > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com> Matches the writing on the tin. The effect is to s/intel_crtc->config->cpu_transcoder/intel_crtc->pipe/ and aiu

Re: [PATCH] dma-buf: remove redundant initialization of sg_table

etected by clang scan-build: > "warning: Value stored to 'sg_table' during its initialization is > never read" > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris _

Re: [PATCH] drm/i915: remove redundant variable hw_check

stored to 'hw_check' during its initialization > is never read" > > Fixes: f6d1973db2d2 ("drm/i915: Move modeset state verifier calls") > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> > --- >

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

Quoting Christian König (2017-09-11 10:57:57) > Am 11.09.2017 um 11:23 schrieb Chris Wilson: > > Quoting Christian König (2017-09-11 10:06:50) > >> Am 11.09.2017 um 10:59 schrieb Chris Wilson: > >>> Quoting Christian König (2017-09-11 09:50:40) > >>>>

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

Quoting Christian König (2017-09-11 10:06:50) > Am 11.09.2017 um 10:59 schrieb Chris Wilson: > > Quoting Christian König (2017-09-11 09:50:40) > >> Sorry for the delayed response, but your mail somehow ended up in the > >> Spam folder. > >> > >>

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

Quoting Christian König (2017-09-11 09:50:40) > Sorry for the delayed response, but your mail somehow ended up in the > Spam folder. > > Am 04.09.2017 um 15:40 schrieb Chris Wilson: > > Quoting Christian König (2017-09-04 14:27:33) > >> From: Christian Köni

Re: [Intel-gfx] [-PATCH v5 1/5] drm/i915: update cursors asynchronously through atomic

Quoting Gustavo Padovan (2017-09-08 20:24:15) > @@ -13167,6 +13170,26 @@ static int intel_atomic_commit(struct drm_device > *dev, > struct drm_i915_private *dev_priv = to_i915(dev); > int ret = 0; > > + /* > +* The atomic async update fast path takes care > +

Re: [PATCH v2 2/2] dma-buf/sw_sync: force signal all unsignaled fences on dying timeline

Quoting Gustavo Padovan (2017-09-08 14:03:00) > Hi Chris, > > 2017-09-07 Chris Wilson <ch...@chris-wilson.co.uk>: > > > Quoting Gustavo Padovan (2017-09-07 20:02:46) > > > From: Dominik Behr <db...@chromium.org> > > > > > > To avoid

Re: [PATCH v2 2/2] dma-buf/sw_sync: force signal all unsignaled fences on dying timeline

ne. > > This restore the default behaviour of the Android sw_sync framework, which > Android still relies on. It was broken on the dma fence conversion a few > years ago and never fixed. > > v2: Do not bother with cleanup do the list (Chris Wilson) > > Signed-off-by: D

Re: [PATCH v2 1/2] selftests: sync: add test that waits on a destroyed timeline

Quoting Gustavo Padovan (2017-09-07 20:02:45) > From: Emilio López > > If a sw_sync_timeline is destroyed the fences associated to it need > to be signalled. This test checks that. > > Cc: Shuah Khan > Cc: linux-kselft...@vger.kernel.org >

Re: [PATCH 2/2] dma-buf/sw_sync: force signal all unsignaled fences on dying timeline

Quoting Gustavo Padovan (2017-09-05 00:06:04) > From: Dominik Behr > > To avoid hanging userspace components that might have been waiting on the > active fences of the destroyed timeline we need to signal with error all > remaining fences on such timeline. > > This restore

Re: [PATCH 0/4] RFC: drm: Allow driver-specific ioctls to be registered

Quoting Marius Vlad (2017-09-04 16:16:41) > From: Marius Vlad > > Currently driver-specific ioctls have to be declared static and are confined > to > DRM core driver. This patch series provides the means to remove those > constrains > and allow to register

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

Quoting Christian König (2017-09-04 14:27:33) > From: Christian König > > The logic is buggy and unnecessary complex. When dma_fence_get_rcu() fails to > acquire a reference it doesn't necessary mean that there is no fence at all. > > It usually mean that the fence was

Re: [Intel-gfx] [RFC PATCH 1/5] drm/i915: Always wait for flip_done

Quoting Maarten Lankhorst (2017-08-30 13:17:48) > The next commit removes the wait for flip_done in in > drm_atomic_helper_commit_cleanup_done, but we need it for the tests > to pass. Instead of using complicated vblank tracking which ends > up being ignored anyway, call the correct atomic helper.

[PATCH 2/2] dma-buf/fence: Sparse wants __rcu on the object itself

In order to silent sparse in dma_fence_get_rcu_safe(), we need to mark the incoming fence object as being RCU protected and not the pointer to the object. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> --- include/linux/dma-fence.h | 2 +- 1 file changed, 1 insertion(+), 1 de

[PATCH 1/2] drm/syncobj: Mark up the fence as an RCU protected pointer

We take advantage of that syncobj->fence is an RCU-protected pointer, and so sparse complains that it is lacking annotation. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> --- include/drm/drm_syncobj.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/in

Re: [Intel-gfx] [PATCH] drm: Release driver tracking before making the object available again

Quoting Daniel Vetter (2017-08-21 17:16:24) > On Sat, Aug 19, 2017 at 01:05:58PM +0100, Chris Wilson wrote: > > This is the same bug as we fixed in commit f6cd7daecff5 ("drm: Release > > driver references to handle before making it available again"), but now > >

[PATCH] drm: Squelch DEBUG_ATOMIC message for pointer manipulations

. A debug message that summarized the action about to be taken would be useful. As it stands the signal:noise of a drm.debug=0x1e dmesg is verging on the useless. We need to curb the overuse of DRM_DEBUG_ATOMIC or stop including it in the recommended debug flags. Signed-off-by: Chris Wilson <ch...@ch

[PATCH] drm: Release driver tracking before making the object available again

l generate a new handle, thus for a short window that object is known to userspace by two different handles. Fix this by releasing the driver tracking before PRIME. Fixes: 0ff926c7d4f0 ("drm/prime: add exported buffers to current fprivs imported buffer list (v2)") Signed-off-by: Chris

Re: [PATCH] drm/doc: Document ioctl errno value patterns

Quoting Daniel Vetter (2017-08-18 10:21:24) > We're not super-consistent about these, but I think it's worth to > document at least the commmon patterns. > > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Chris Wilson <ch...@chris-wilson.co.uk> &

Re: [PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf

Quoting Laurent Pinchart (2017-08-18 09:01:38) > Hi Daniel, > > On Friday 18 Aug 2017 09:45:48 Daniel Vetter wrote: > > On Fri, Aug 18, 2017 at 01:35:41AM +0300, Laurent Pinchart wrote: > > > Fair enough. I wonder, however, why mmap()ing an imported buffer through > > > the dumb buffers API is an

Re: [PATCH v2] drm/i915: Fix integer overflow tests

Quoting Dan Carpenter (2017-08-18 08:07:00) > There are some potential integer overflows here on 64 bit systems. > > The condition "if (nfences > SIZE_MAX / sizeof(*fences))" can only be > true on 32 bit systems, it's a no-op on 64 bit, so let's ignore the > check for now and look a couple lines

Re: [PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf

Quoting Laurent Pinchart (2017-08-17 20:40:52) > Hi Chris, > > On Thursday 17 Aug 2017 20:09:20 Chris Wilson wrote: > > Quoting Laurent Pinchart (2017-08-17 20:01:40) > > > On Thursday 17 Aug 2017 19:30:44 Chris Wilson wrote: > > > > Quoting L

Re: [PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf

Quoting Laurent Pinchart (2017-08-17 20:01:40) > Hi Chris, > > On Thursday 17 Aug 2017 19:30:44 Chris Wilson wrote: > > Quoting Laurent Pinchart (2017-08-17 18:56:09) > > > On Thursday 17 Aug 2017 18:21:30 Noralf Trønnes wrote: > > > > Reject mapping an import

Re: [PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf

Quoting Laurent Pinchart (2017-08-17 18:56:09) > Hi Noralf, > > Thank you for the patch. > > On Thursday 17 Aug 2017 18:21:30 Noralf Trønnes wrote: > > Reject mapping an imported dma-buf since is's an invalid use-case. > > > > Cc: Philipp Zabel > > Cc: Laurent Pinchart

Re: [PATCH] drm: Wake up all waiters for the vblank

Quoting Ville Syrjälä (2017-08-17 15:56:19) > On Thu, Aug 17, 2017 at 01:27:41PM +0100, Chris Wilson wrote: > > As we have a single list for vblank waiters (not sorted by the vblank > > they are waiting for), make sure we wake up all waiters rather than just > > the first as

[PATCH] drm: Wake up all waiters for the vblank

As we have a single list for vblank waiters (not sorted by the vblank they are waiting for), make sure we wake up all waiters rather than just the first as we may have multiple consumers for this vblank event. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Maarten Lan

Re: [patch net-next 0/3] net/sched: Improve getting objects by indexes

Quoting Christian König (2017-08-16 08:49:07) > Am 16.08.2017 um 04:12 schrieb Chris Mi: > > Using current TC code, it is very slow to insert a lot of rules. > > > > In order to improve the rules update rate in TC, > > we introduced the following two changes: > > 1) changed cls_flower to

Re: [PATCH 2/2] drm/tegra: gem: Implement mmap() for PRIME buffers

_prime_map_dma_buf(struct dma_buf_attachment *attach, > enum dma_data_direction dir) > @@ -603,7 +614,14 @@ static void tegra_gem_prime_kunmap(struct dma_buf *buf, > unsigned long page, > > static int tegra_gem_prime_mmap(struct dma_buf *buf, struct vm_area_struct > *vm

Re: [PATCH] dma-buf/dma-fence: Signal all callbacks from dma_fence_release()

Quoting Christian König (2017-08-13 14:04:29) > Am 11.08.2017 um 19:01 schrieb Chris Wilson: > > This is an illegal scenario, to free the fence whilst there are pending > > callbacks. Currently, we emit a WARN and then cast aside the callbacks > > leaving them dangling. Altern

[PATCH] drm: RCU syncobj

can do a lockless drm_syncobj_find(). Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> --- drivers/gpu/drm/drm_syncobj.c | 10 +- include/drm/drm_syncobj.h | 2 ++ 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/g

Re: [PATCH 2/9] drm/syncobj: Lock around drm_syncobj::fence

Quoting Jason Ekstrand (2017-08-10 01:31:52) > > > On Wed, Aug 9, 2017 at 2:21 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > > Quoting Jason Ekstrand (2017-08-08 23:46:02) > > The atomic exchange operation we were doing before in replace_fence was >

Re: [PATCH 2/2] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

Quoting Christian König (2017-08-10 19:19:52) > Am 10.08.2017 um 19:11 schrieb Chris Wilson: > > Quoting Alex Deucher (2017-08-10 18:01:49) > >> From: Christian König <christian.koe...@amd.com> > >> > >> With hardware resets in mind it is possibl

Re: [PATCH 2/2] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

Quoting Alex Deucher (2017-08-10 18:01:49) > From: Christian König > > With hardware resets in mind it is possible that all shared fences are > signaled, but the exlusive isn't. Fix waiting for everything in this > situation. I'm still puzzling over this one. Setting

Re: [PATCH] drm/syncobj: Allow wait for submit and signal behavior (v2)

Quoting Jason Ekstrand (2017-08-10 00:53:00) > On Wed, Aug 9, 2017 at 3:41 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > However, this installs the proxy into syncobj->fence with the result > that any concurrent wait also become a WAIT_FOR_SUBMIT. The behaviour &g

Re: [PATCH 2/9] drm/syncobj: Lock around drm_syncobj::fence

Quoting Jason Ekstrand (2017-08-10 01:31:52) > > > On Wed, Aug 9, 2017 at 2:21 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > > Quoting Jason Ekstrand (2017-08-08 23:46:02) > > The atomic exchange operation we were doing before in replace_fence was >

Re: [PATCH] drm/vgem: Couple in drm_syncobj support

Quoting Jason Ekstrand (2017-08-10 02:02:43) > On Wed, Aug 9, 2017 at 12:03 PM, Chris Wilson <ch...@chris-wilson.co.uk> > wrote: > > To further facilitate GEM testing, allow testing of drm_syncobj by > attaching them to vgem fences. These fences are al

Re: [PATCH] drm/syncobj: Allow wait for submit and signal behavior (v2)

Quoting Chris Wilson (2017-08-09 18:57:44) > So we are taking a snapshot here. It looks like this could have been > done using a dma_fence_array + dma_fence_proxy for capturing the future > fence. A quick sketch of this idea looks like: void drm_syncobj_replace_fence(struct drm_syncobj

Re: [PATCH] drm/syncobj: Allow wait for submit and signal behavior (v2)

Quoting Jason Ekstrand (2017-08-09 18:00:54) > +static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj > **syncobjs, > + uint32_t count, > + uint32_t flags, > +

Re: [PATCH 2/9] drm/syncobj: Lock around drm_syncobj::fence

Quoting Jason Ekstrand (2017-08-08 23:46:02) > The atomic exchange operation we were doing before in replace_fence was > sufficient for the case where it raced with itself. However, if you > have a race between a replace_fence and dma_fence_get(syncobj->fence), > you may end up with the entire

[PATCH] drm/vgem: Couple in drm_syncobj support

ence as both are handles in an idr (the fence here is not a sync-file fd like in most other drivers). The main benefit for syncobj is that it allows to create channels between objects and drivers by virtue of its persistence beyond the vgem fence itself. Signed-off-by: Chris Wilson <ch..

Re: [PATCH] drm/syncobj: Allow wait for submit and signal behavior (v2)

Quoting Jason Ekstrand (2017-08-09 18:00:54) > Vulkan VkFence semantics require that the application be able to perform > a CPU wait on work which may not yet have been submitted. This is > perfectly safe because the CPU wait has a timeout which will get > triggered eventually if no work is ever

[PATCH] drm: Wake up next in drm_read() chain if we are forced to putback the event

or a new waiter appears. Rare, but in the worst case may lead to a stuck process. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vet...@ffwll.ch> --- drivers/gpu/drm/drm_file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/

Re: [PATCH 3/5] drm/syncobj: add sync_file interaction.

Quoting Dave Airlie (2017-08-04 00:01:10) > On 4 August 2017 at 02:25, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > > Quoting Dave Airlie (2017-05-12 01:34:55) > >> @@ -385,6 +434,13 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_devic

Re: [PATCH] i915: Add support for drm syncobjs

Quoting Jason Ekstrand (2017-08-03 19:06:02) > I'm not concerned about what happens to racy clients.  They get what they > get.  > What concerns me is what happens if somehow the fence is replaced and deleted > before i915_gem_request_await_dma_fence takes it's reference.  Can this cause > the

Re: [PATCH] i915: Add support for drm syncobjs

Quoting Jason Ekstrand (2017-07-05 22:15:09) > On Wed, Jul 5, 2017 at 2:13 PM, Jason Ekstrand wrote: > > This commit adds support for waiting on or signaling DRM syncobjs as > part of execbuf.  It does so by hijacking the currently unused cliprects > pointer to

Re: [PATCH 3/5] drm/syncobj: add sync_file interaction.

Quoting Dave Airlie (2017-05-12 01:34:55) > @@ -385,6 +434,13 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, > void *data, > if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ)) > return -ENODEV; > > + if (args->flags & >

Re: [PATCH 3/3] selftests: sync: add test that closes the fd before fence signal

should be entering the timeline_inc loop with fence.refcount==0 rather than the refcount going to zero within the loop. To achieve that we need to find a callback that does unreference a dma-fence and chain those together so that it frees a sw_sync from the same timeline. Still add the comment

Re: [PATCH 2/3] dma-buf/sw_sync: clean up list before signaling the fence

rst. > > v2: Drop the fence get/put dance and manipulate the list first (Chris Wilson) > > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.com> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> -Chris _

Re: [PATCH 1/3] dma-buf/sw_sync: move timeline_fence_ops around

Quoting Gustavo Padovan (2017-07-29 16:22:15) > From: Gustavo Padovan <gustavo.pado...@collabora.com> > > We are going to use timeline_fence_signaled() in a internal function in > the next commit. > > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Signed-off-

[PATCH] dma-buf/sync_file: Allow multiple sync_files to wrap a single dma-fence

420bbac ("drm: introduce sync objects (v4)") Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Sumit Semwal <sumit.sem...@linaro.org> Cc: Sean Paul <seanp...@chromium.org> Cc: Gustavo Padovan <gust...@padovan.org> Cc: dri-devel@lists.freedesktop.org Cc: <dr

Re: [PATCH] vc4: Add an ioctl for labeling GEM BOs for summary stats

Quoting Eric Anholt (2017-07-25 19:27:25) > Chris Wilson <ch...@chris-wilson.co.uk> writes: > > > Quoting Eric Anholt (2017-06-22 21:50:54) > >> This has proven immensely useful for debugging memory leaks and > >> overallocation (which is a rather serious

Re: [PATCH] dma-buf/sw_sync: hold a fence reference when check if it signaled

Quoting Gustavo Padovan (2017-07-28 02:57:25) > 2017-07-27 Chris Wilson <ch...@chris-wilson.co.uk>: > > > Quoting Gustavo Padovan (2017-07-27 20:03:53) > > > From: Gustavo Padovan <gustavo.pado...@collabora.com> > > > > > > If userspace alrea

Re: [PATCH] dma-buf/sw_sync: hold a fence reference when check if it signaled

release of the fence a > thus try to hold the lock to remove the fence from the list. So the issue here is that call to dma_fence_is_signaled_lock() is triggering the unreference? > We need to grab a reference to the fence before calling into this chain if > we want to avoid this is

Re: [PATCH] vc4: Add an ioctl for labeling GEM BOs for summary stats

Quoting Eric Anholt (2017-06-22 21:50:54) > This has proven immensely useful for debugging memory leaks and > overallocation (which is a rather serious concern on the platform, > given that we typically run at about 256MB of CMA out of up to 1GB > total memory, with framebuffers that are about 8MB

Re: [PATCH] drm/udl: Make page_flip asynchronous

mbedding it tino the udl_device, flip_queue.wq provides the safety check after initialisation. I couldn't spot anything drastically wrong, certainly it looks complete, I would have structured it such that everything went through the same worker with a hrtimer emulating the vblan

Re: [PATCH 2/2] drm/dp: Don't trust drm_dp_downstream_id()

Quoting Jani Nikula (2017-07-21 08:22:27) > On Thu, 20 Jul 2017, Chris Wilson <ch...@chris-wilson.co.uk> wrote: > > Before we interpret drm_dp_downstream_id() as a string, make sure it is > > NULL terminated, even when drm_dp_downtsream_id() fails. > > > > Bugzi

[PATCH 1/2] drm/dp: Fix read pointer for drm_dp_downsteam_debug()

Pass in the array and not a pointer to the array to drm_dp_dpcd_read(). Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> --- drivers/gpu/drm/drm_dp_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_he

[PATCH 2/2] drm/dp: Don't trust drm_dp_downstream_id()

Before we interpret drm_dp_downstream_id() as a string, make sure it is NULL terminated, even when drm_dp_downtsream_id() fails. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101660 Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> --- drivers/gpu/drm/drm_dp_helper.c | 3

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'

Quoting Tvrtko Ursulin (2017-07-20 11:09:53) > > On 19/07/2017 23:35, Christophe JAILLET wrote: > > Goto the right label in case of error, otherwise there is a leak. > > This has been introduced by c5cf9a9147ff. In this patch a goto has not been > > updated. > > > > Fixes: c5cf9a9147ff

Re: [PATCH] drm: Prevent early NULL dereference of fb_helper->fb

Quoting Daniel Vetter (2017-07-20 09:26:32) > On Wed, Jul 19, 2017 at 04:24:50PM +0100, Chris Wilson wrote: > > Prior to the fbdev being asynchronously configured on boot, the > > fb_helper->fb may be unset. > > > > Bugzilla: https://bugs.freedesktop.org/show_bu

[PATCH] drm: Prevent early NULL dereference of fb_helper->fb

Prior to the fbdev being asynchronously configured on boot, the fb_helper->fb may be unset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101767 Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Thierry Reding <tred...@nvidia.com> Cc: Daniel Vetter <dani

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Remove intel_flip_work infrastructure

Quoting Daniel Vetter (2017-07-19 14:24:20) > On Wed, Jul 19, 2017 at 02:07:36PM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-07-19 13:55:01) > > > This gets rid of all the interactions between the legacy flip code and > > > the modeset code. Yay! > >

Re: [Intel-gfx] [PATCH 7/9] drm/i915: adjust has_pending_fb_unpin to atomic

Quoting Daniel Vetter (2017-07-19 14:15:44) > On Wed, Jul 19, 2017 at 02:06:43PM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-07-19 13:55:00) > > > A bit an oversight - the current code did nothing, since only > > > legacy flips used the unpin_wo

Re: [PATCH 5/9] drm/i915: More surgically unbreak the modeset vs reset deadlock

is for pre-g4x hw, of questionable > utility just for the sake of polishing gpu reset even more on those > old boxes. It might be useful for other features though. > > v2: Rebase onto 4.13 with a s/wait_queue_t/struct wait_queue_entry/. > > Cc: Chris Wilson <ch...@chris

Re: [PATCH 3/9] drm/i915: Avoid the gpu reset vs. modeset deadlock

Quoting Daniel Vetter (2017-07-19 13:54:56) > ... using the biggest hammer we have. This is essentially a weaponized > version of the timeout-based wedging Chris added in > > commit 36703e79a982c8ce5a8e43833291f2719e92d0d1 > Author: Chris Wilson <ch...@chris-wilson.co.uk> &g

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Drop unpin stall in atomic_prepare_commit

Quoting Daniel Vetter (2017-07-19 13:55:02) > The core already does this in setup_commit(). With this we can also > remove the unpin_work_count since it's the last user. Also note that the loop only existed for the legacy pageflip support, with that removed it becomes entirely redundant. -Chris

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Remove intel_flip_work infrastructure

Quoting Daniel Vetter (2017-07-19 13:55:01) > This gets rid of all the interactions between the legacy flip code and > the modeset code. Yay! Including our missed vblank boosting. (That's been dead for a while.) -Chris ___ dri-devel mailing list

Re: [Intel-gfx] [PATCH 7/9] drm/i915: adjust has_pending_fb_unpin to atomic

Quoting Daniel Vetter (2017-07-19 13:55:00) > A bit an oversight - the current code did nothing, since only > legacy flips used the unpin_work_count and assorted logic. > > Cc: Maarten Lankhorst > Cc: Ville Syrjälä >

Re: [PATCH 4/9] drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit

Quoting Daniel Vetter (2017-07-19 13:54:57) > Blocking in a worker is ok, but needlessly inefficient, > that's what the unbound_wq is for. And it > unifies the paths between the blocking and nonblocking commit, giving > me just one path where I have to implement the deadlock avoidance >

Re: [PATCH] drm/msm/mdp5: Fix compilation warnings

Quoting Viresh Kumar (2017-06-29 10:19:59) > Following compilation warnings were observed for these files: > > CC [M] drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.o > drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c: In function 'blend_setup': > drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:223:7: warning:

Re: [PATCH v12 6/6] drm/i915: Introduce GEM proxy

s/GEM proxy/a GEM proxy object/ Quoting Tina Zhang (2017-07-19 11:59:05) Rationale goes here. > Signed-off-by: Tina Zhang > --- > drivers/gpu/drm/i915/i915_gem.c| 26 +- > drivers/gpu/drm/i915/i915_gem_object.h | 9 + >

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event

Quoting Paul Kocialkowski (2017-07-18 16:16:26) > It may occur that a hotplug uevent is detected at resume, even though it > does not indicate that an actual hotplug happened. This is the case when > link training fails on any other connector. > > There is currently no way to distinguish what

Re: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex.

org> > Cc: Ingo Molnar <mi...@redhat.com> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> But fwiw, the patch isn't wrong and fixes a false positive, so Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> > drivers/gpu/drm/drm_gem.c | 8 +--- > 1 file cha

Re: [PATCH 1/3] drm/atomic-helper: Fix leak in disable_all

Quoting Daniel Vetter (2017-07-14 23:46:54) > @@ -2902,6 +2907,8 @@ int drm_atomic_helper_commit_duplicated_state(struct > drm_atomic_state *state, > struct drm_connector_state *new_conn_state; > struct drm_crtc *crtc; > struct drm_crtc_state *new_crtc_state; > +

Re: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex.

Quoting Daniel Vetter (2017-07-15 10:53:28) > For modern drivers the DRM core doesn't use struct_mutex at all, which > means it's defacto a driver-private lock. But since we still need it > for legacy drivers we can't initialize it in drivers, which means all > the different instances share one

Re: [Intel-gfx] [PATCH 3/3] drm/i915: unregister interfaces first in unload

aniel.vet...@ffwll.ch> Just some concern from the inertia of having the old order for years, but this looks completely correct to me. That the driver may still be active as we disable the userspace interfaces should not affect those. Reviewed-by: Chris Wilson <ch...

Re: [PATCH 2/3] drm/i915: Fix fbdev unload sequence

Quoting Daniel Vetter (2017-07-14 20:14:38) Second nit: > +void intel_fbdev_fini(struct drm_i915_private *dev_priv) > +{ > + struct intel_fbdev *ifbdev = dev_priv->fbdev; > + > + if (!ifbdev) > + return; > + > intel_fbdev_destroy(ifbdev); >

Re: [PATCH 2/3] drm/i915: Fix fbdev unload sequence

https://bugs.freedesktop.org/show_bug.cgi?id=101791 > Cc: martin.pe...@free.fr > Cc: ch...@chris-wilson.co.uk > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> Splitting out the unregister and running it early makes sense and is how we expect to unload to proceed. Reviewed

Re: [PATCH 1/3] drm/atomic-helper: Fix leak in disable_all

this issue. If only we have refcounted fb now and didn't need every caller manually tracking the old pointers. Given the requirement for the caller to cleanup old_fb around drm_atomic_commit(), this looks correct to me. > Cc: martin.pe...@free.fr > Cc: ch...@chris-wilson.co.uk > Signed-

Re: 4.9-rc1 lockdep warning suggesting a deadlock between nouveau and i915 with prime video outputs active

Quoting Jiri Slaby (2017-07-13 14:57:31) > Stealing this thread as an opensuse user hit that too: > https://bugzilla.suse.com/show_bug.cgi?id=1045105 It's a false positive. I did once upon a time send some patches to move the lockdep warning to kref so that didn't need to call it from drm before

Re: [PATCH] dma-buf/fence: Avoid use of uninitialised timestamp

Quoting Chris Wilson (2017-02-14 12:40:01) > [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized > memory (8802538683d0) > [ 236.828642] > 42001e7f0008 > [ 236.839543] i i i i u u u u i i i i i i i i

Re: [PATCH 3/3] drm/msm: hijack firmware fb's memory

Quoting Rob Clark (2017-07-11 14:38:22) > +static unsigned long hijack_firmware_fb(struct drm_device *dev) > +{ > + struct msm_drm_private *priv = dev->dev_private; > + unsigned long size; > + int i; > + > + /* if we have simplefb/efifb, find it's aperture and hijack > +

[PATCH] drm: Remove unused drm_file parameter to drm_syncobj_replace_fence()

the drm_file parameter is unused, so remove it. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Dave Airlie <airl...@redhat.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 ++ drivers/gpu/drm/drm_syncobj.c | 8 +++- include/drm/drm_syncobj.h

Re: [PATCH] i915: Add support for drm syncobjs

Quoting Jason Ekstrand (2017-07-05 19:32:21) > On Wed, Jul 5, 2017 at 10:37 AM, Chris Wilson <ch...@chris-wilson.co.uk> > wrote: > > Quoting Jason Ekstrand (2017-07-05 18:21:22) > > This commit adds support for waiting on or signaling DRM syncobjs as > >

<    6   7   8   9   10   11   12   13   14   15   >