Quoting Chris Wilson (2019-08-09 12:58:51)
> Quoting Lionel Landwerlin (2019-08-09 12:30:30)
> > + if (flags & I915_DRM_SYNCOBJ_BINARY_ITEM_VALUE_READ) {
> > + copy_to_user(&values[i],
> > &syncobjs[i]
Quoting Lionel Landwerlin (2019-08-09 13:38:57)
> On 09/08/2019 14:58, Chris Wilson wrote:
> > Not atomic (the u64 write should really be to avoid total corruption)
> > and nothing prevents userspace from racing. How safe is that in the
> > overall design?
>
>
&
Quoting Matthew Auld (2019-08-09 23:26:08)
> diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
> b/drivers/gpu/drm/i915/intel_memory_region.c
> new file mode 100644
> index ..ef12e462acb8
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_memory_region.c
> @@ -0,0 +1,175 @@
> +//
Quoting Matthew Auld (2019-08-09 23:26:09)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6ff01a404346..8735dea74809 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1105,6 +1105,23 @@ i915_gem_madvise_ioctl(struc
Quoting Matthew Auld (2019-08-09 23:26:10)
> Some objects may need to be allocated as a continuous block, thinking
> ahead the various kernel io_mapping interfaces seem to expect it.
But we could always use scattergather over top...
> @@ -98,10 +101,12 @@ i915_gem_object_get_pages_buddy(struct
>
hat's quite a nice generalisation.
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Matthew Auld (2019-08-09 23:26:11)
> Volatile objects are marked as DONTNEED while pinned, therefore once
> unpinned the backing store can be discarded.
Do we also have the concept of non-volatile backing store, e.g. shmemfs
(non-volatile) vs stolen (volatile)?
-Chris
_
Quoting Matthew Auld (2019-08-09 23:26:12)
> From: Abdiel Janulgue
>
> Exposes available regions for the platform. Shared memory will
> always be available.
>
> Signed-off-by: Abdiel Janulgue
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/
Quoting Matthew Auld (2019-08-09 23:26:13)
> @@ -1369,6 +1371,8 @@ struct drm_i915_private {
> */
> resource_size_t stolen_usable_size; /* Total size minus reserved
> ranges */
>
> + struct intel_memory_region *regions[INTEL_MEMORY_UKNOWN];
If there was ever an object
Quoting Matthew Auld (2019-08-09 23:26:18)
> +struct i915_vma *intel_emit_vma_copy_blt(struct intel_engine_pool_node **p,
> +struct intel_context *ce,
> +struct i915_vma *src,
> +
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Matthew Auld (2019-08-09 23:26:22)
> @@ -1017,10 +1020,14 @@ static void reloc_cache_reset(struct reloc_cache
> *cache)
> } else {
> struct i915_ggtt *ggtt = cache_to_ggtt(cache);
>
> - intel_gt_flush_ggtt_writes(ggtt->vm.gt);
> + if (!
Quoting Matthew Auld (2019-08-09 23:26:25)
> From: Abdiel Janulgue
>
> Nothing to enumerate yet...
>
> Signed-off-by: Abdiel Janulgue
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> drivers/gpu/drm/i915/i915_gem_gtt.c
Quoting Matthew Auld (2019-08-09 23:26:29)
> From: Daniele Ceraolo Spurio
>
> Skip both setup and cleanup of the aperture mapping if the HW doesn't
> have an aperture bar.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 36 +++
Quoting Matthew Auld (2019-08-09 23:26:32)
> From: Daniele Ceraolo Spurio
>
> If the aperture is not available in HW we can't use a ggtt slot and wc
> copy, so fall back to regular kmap.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Abdiel Janulgue
> ---
> drivers/gpu/drm/i915/i9
Quoting Matthew Auld (2019-08-09 23:26:33)
> From: Michal Wajdeczko
>
> HWS placement restrictions can't just rely on HAS_LLC flag.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 de
Quoting Matthew Auld (2019-08-09 23:26:34)
> From: CQ Tang
>
> Signed-off-by: CQ Tang
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 2aa
Quoting Matthew Auld (2019-08-09 23:26:35)
> From: Abdiel Janulgue
>
> This enables us to store extra data within vma->vm_private_data and assign
> the pagefault ops for each mmap instance.
>
> We replace the core drm_gem_mmap implementation to overcome the limitation
> in having only a single o
Quoting Matthew Auld (2019-08-09 23:26:36)
> From: Abdiel Janulgue
>
> Add a new CPU mmap implementation that allows multiple fault handlers
> that depends on the object's backing pages.
>
> Note that we multiplex mmap_gtt and mmap_offset through the same ioctl,
> and use the zero extending beha
Quoting Matthew Auld (2019-08-09 23:26:38)
> -void __i915_gem_object_release_mmap(struct drm_i915_gem_object *obj)
> +static vm_fault_t i915_gem_fault_cpu(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *area = vmf->vma;
> + struct i915_mmap_offset *priv = area->vm_private_data;
>
Quoting Matthew Auld (2019-08-09 23:26:39)
> From: Abdiel Janulgue
>
> If there is no aperture we can't use map_gtt to map dumb buffers, so we
> need a cpu-map based path to do it. We prefer map_gtt on platforms that
> do have aperture.
>
> Signed-off-by: Abdiel Janulgue
> Cc: Daniele Ceraolo S
Quoting Matthew Auld (2019-08-09 23:26:40)
> We are going want to able to move objects between different regions
> like system memory and local memory. In the future everything should
> be just another region.
>
> Signed-off-by: Matthew Auld
> Signed-off-by: Abdiel Janulgue
> Signed-off-by: CQ T
Quoting Matthew Auld (2019-08-09 23:26:41)
> From: Abdiel Janulgue
>
> This call will specify which memory region an object should be placed.
>
> Note that changing the object's backing storage should be immediately
> done after an object is created or if it's not yet in use, otherwise
> this wi
Quoting Matthew Auld (2019-08-09 23:26:42)
> From: Abdiel Janulgue
>
> Returns the available memory region areas supported by the HW.
And how does one use this information?
How does this relate to the information presented by Vulkan or OpenCL
Testcase: igt/...?
New uAPI should always come wi
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
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
Cc: Tvrtko Ursulin
---
drivers/dma-buf/Makef
always notify the callbacks.
The cost is that dma_fence_signal() must always acquire the spinlock to
ensure that the cb_list is flushed.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/dma-fence.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.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
Now that dma_fence_signal always takes the spinlock to flush the
cb_list, simply take the spinlock and call dma_fence_signal_locked() to
avoid code repetition.
Suggested-by: Christian König
Signed-off-by: Chris Wilson
Cc: Christian König
---
drivers/dma-buf/dma-fence.c | 32
), and overwhelmingly agreeing with
the motivation,
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Koenig, Christian (2019-08-11 09:58:31)
> Am 10.08.19 um 17:34 schrieb Chris Wilson:
> > + /*
> > + * Propagate the first error reported by any of our fences, but only
> > + * before we ourselves are signaled.
> > + */
> > + if (ato
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.
v3: Be careful not to flag an error if we race against signal-on-any
Signed-off-by: Chris Wilson
Cc: Sumit
signal cb.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
---
drivers/dma-buf/dma-fence-array.c | 37 ++-
include/linux/dma-fence-array.h | 2 ++
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma
signal cb.
v5: Use cmpxchg to only set the error once before using a nifty idea by
Christian to avoid changing the status after emitting the signal.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
---
drivers/dma-buf/dma-fence-array.c | 32
signal cb.
v5: Use cmpxchg to only set the error once before using a nifty idea by
Christian to avoid changing the status after emitting the signal.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence
signal cb.
v5: Use cmpxchg to only set the error once before using a nifty idea by
Christian to avoid changing the status after emitting the signal.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Christian König
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence
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
Reviewed-by: Matthew Auld
---
drivers/dma-buf/sync_file.c | 2 +-
1 file changed
Quoting Koenig, Christian (2019-08-12 15:34:32)
> Am 10.08.19 um 17:34 schrieb Chris Wilson:
> > 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 rat
Quoting Koenig, Christian (2019-08-12 15:50:59)
> Am 12.08.19 um 16:43 schrieb Chris Wilson:
> > Quoting Koenig, Christian (2019-08-12 15:34:32)
> >> Am 10.08.19 um 17:34 schrieb Chris Wilson:
> >>> Move the duplicated code within dma-fence.c into the header for wid
lla: https://bugs.freedesktop.org/show_bug.cgi?id=111381
Fixes: d3862e44daa7 ("dma-buf/sw-sync: Fix locking around sync_timeline lists")
References: 0e2f733addbf ("dma-buf: make dma_fence structure a bit smaller v2")
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Pa
Quoting Koenig, Christian (2019-08-13 07:59:28)
> Am 12.08.19 um 16:53 schrieb Chris Wilson:
> > Quoting Koenig, Christian (2019-08-12 15:50:59)
> >> Am 12.08.19 um 16:43 schrieb Chris Wilson:
> >>> Quoting Koenig, Christian (2019-08-12 15:34:32)
> >>>&
Quoting Daniel Vetter (2019-08-14 16:39:08)
> Sorry I burried myself in some other stuff ...
>
> On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> > Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > > Quoting Christian König (2019-08-07 14:53:12)
> >
Quoting Chris Wilson (2019-08-14 17:42:48)
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> >
> > What if someone is real fast (like really real fast) and recycles the
> > exclusive f
Quoting Daniel Vetter (2019-08-14 18:06:26)
> On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-08-14 16:39:08)
[snip]
> > > > > > if (old)
> > > > > > - old->shared_count = 0;
Quoting Chris Wilson (2019-08-14 18:06:18)
> Quoting Chris Wilson (2019-08-14 17:42:48)
> > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > >
> > > What if someone is re
Quoting Chris Wilson (2019-08-14 18:22:53)
> Quoting Chris Wilson (2019-08-14 18:06:18)
> > Quoting Chris Wilson (2019-08-14 17:42:48)
> > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > > + } while (rcu_access_pointer(obj->fence_excl) != *
Quoting Chris Wilson (2019-08-14 18:38:20)
> Quoting Chris Wilson (2019-08-14 18:22:53)
> > Quoting Chris Wilson (2019-08-14 18:06:18)
> > > Quoting Chris Wilson (2019-08-14 17:42:48)
> > > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > >
---
drivers/gpu/drm/i915/Makefile | 7 +
drivers/gpu/drm/i915/ttm/Makefile | 5 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.c | 4 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.h | 12 ++
drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c | 174 ++
drivers/gpu/drm/i
Quoting Chris Wilson (2019-08-14 19:22:54)
You saw nothing; wrong experimental branch.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
hat no
fence was changed in the dma_resv after a read (or full) memory barrier.
Signed-off-by: Chris Wilson
Cc: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 31 -
drivers/dma-buf/dma-resv.c| 109 -
.../gpu/drm
Quoting Chris Wilson (2019-08-14 19:24:01)
> This reverts
> 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
> dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
> 0e1d8083bddb ("dma-buf: further relax reservation_object_add_sh
Quoting Koenig, Christian (2019-08-14 18:58:32)
> Am 14.08.19 um 19:48 schrieb Chris Wilson:
> > Quoting Chris Wilson (2019-08-14 18:38:20)
> >> Quoting Chris Wilson (2019-08-14 18:22:53)
> >>> Quoting Chris Wilson (2019-08-14 18:06:18)
> >>>&
Quoting Daniel Vetter (2019-08-14 18:20:53)
> On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> > Now that dma_fence_signal always takes the spinlock to flush the
> > cb_list, simply take the spinlock and call dma_fence_signal_locked() to
> > avoid code repetitio
Quoting Daniel Vetter (2019-08-15 19:48:42)
> On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-08-14 18:20:53)
> > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> > > > Now that dma_fence_signal always t
Quoting Chris Wilson (2019-08-15 20:03:13)
> Quoting Daniel Vetter (2019-08-15 19:48:42)
> > On Thu, Aug 15, 2019 at 8:46 PM Chris Wilson
> > wrote:
> > > Quoting Daniel Vetter (2019-08-14 18:20:53)
> > > > On Sun, Aug 11, 2019 at 10:15:23AM +0100, Ch
Quoting Maxime Ripard (2019-08-16 12:32:01)
> Hi Daniel, Dave,
>
> Here's this week drm-misc-next PR.
>
> Maxime
>
> drm-misc-next-2019-08-16:
> drm-misc-next for 5.4:
>
> UAPI Changes:
>
> Cross-subsystem Changes:
>
> Core Changes:
> - dma-buf: add reservation_object_fences helper, relax
>
Before we notify the fence signal callback, we remove the cb from the
list. However, since we are processing the entire list from underneath
the spinlock, we do not need to individual delete each element, but can
simply reset the link and the entire list.
Signed-off-by: Chris Wilson
Cc: Daniel
notify the callbacks on signaling. As such, we will
always need to take the spinlock and dma_fence_signal() effectively
becomes a clone of dma_fence_signal_locked().
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
---
drivers/dma-buf/dma-fence.c | 19 +--
1
Quoting Daniel Vetter (2019-08-16 20:07:24)
> On Fri, Aug 16, 2019 at 9:02 PM Koenig, Christian
> wrote:
> >
> > Am 16.08.19 um 17:21 schrieb Chris Wilson:
> > > Currently dma_fence_signal() tries to avoid the spinlock and only takes
> > > it if absolutel
Rearrange the couple of 32-bit atomics hidden amongst the field of
pointers that unnecessarily caused the compiler to insert some padding,
shrinks the size of the base struct dma_fence from 80 to 72 bytes on
x86-64.
Signed-off-by: Chris Wilson
Cc: Christian König
---
include/linux/dma-fence.h
Quoting Koenig, Christian (2019-08-17 12:42:48)
> Am 17.08.19 um 13:39 schrieb Chris Wilson:
> > Rearrange the couple of 32-bit atomics hidden amongst the field of
> > pointers that unnecessarily caused the compiler to insert some padding,
> > shrinks the size of the base str
Exercise the dma-fence API exported to drivers.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/Makefile | 5 +-
drivers/dma-buf/selftests.h| 1 +
drivers/dma-buf/st-dma-fence.c | 571 +
3 files changed, 576 insertions(+), 1
references are held can be replaced by the rcu_head.
By reusing the union for the timestamp, we squeeze the base dma_fence
struct to 64 bytes on x86-64.
Suggested-by: Christian König
Signed-off-by: Chris Wilson
Cc: Christian König
---
drivers/dma-buf/dma-fence.c | 16
notify the callbacks on signaling. As such, we will
always need to take the spinlock and dma_fence_signal() effectively
becomes a clone of dma_fence_signal_locked().
v2: Update the test_and_set_bit() before entering the spinlock.
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
Rearrange the couple of 32-bit atomics hidden amongst the field of
pointers that unnecessarily caused the compiler to insert some padding,
shrinks the size of the base struct dma_fence from 80 to 72 bytes on
x86-64.
Signed-off-by: Chris Wilson
Cc: Christian König
Reviewed-by: Christian König
st of
selftests and their subtest. The names of the selftests are put into the
modinfo as parameters so that igt can identify each, and run them
independently, principally for ease of error reporting.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/Kconfig | 5 ++
drivers/dm
Before we notify the fence signal callback, we remove the cb from the
list. However, since we are processing the entire list from underneath
the spinlock, we do not need to individual delete each element, but can
simply reset the link and the entire list.
Signed-off-by: Chris Wilson
Cc: Daniel
aller
error so expected to be very unlikely.
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
---
drivers/dma-buf/dma-fence.c | 44 ++---
1 file changed, 12 insertions(+), 32 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-bu
Quoting Koenig, Christian (2019-08-17 16:20:12)
> Am 17.08.19 um 16:47 schrieb Chris Wilson:
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 89d96e3e6df6..2c21115b1a37 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/
references are held can be replaced by the rcu_head.
By reusing the union for the timestamp, we squeeze the base dma_fence
struct to 64 bytes on x86-64.
v2: Sort the union chronologically
Suggested-by: Christian König
Signed-off-by: Chris Wilson
Cc: Christian König
---
drivers/dma-buf/dma-fence.c
st of
selftests and their subtest. The names of the selftests are put into the
modinfo as parameters so that igt can identify each, and run them
independently, principally for ease of error reporting.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Tomi Sarvela
---
drivers/dma-buf/Kconfig
Exercise the dma-fence API exported to drivers.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/Makefile | 5 +-
drivers/dma-buf/selftests.h| 1 +
drivers/dma-buf/st-dma-fence.c | 571 +
3 files changed, 576 insertions(+), 1
ntage that we get a signal when the cb_list is complete,
useful in a few cases that need to serialise against the cb_list.
Suggested-by: Christian König
Signed-off-by: Chris Wilson
Cc: Christian König
---
drivers/dma-buf/dma-fence.c | 41 +++---
drivers/dma-buf/s
Quoting Masanari Iida (2019-08-19 14:05:52)
> This patch fix a spelling typo in test-drm_mm.c
>
> Signed-off-by: Masanari Iida
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freede
Quoting Chris Wilson (2019-08-19 10:59:26)
> In light of recent review slip ups, the absence of a suite of tests for
> dma-buf became apparent. Given the current plethora of testing
> frameworks, opt for one already in use by Intel's CI and so allow easy
> hook up into igt.
>
Include the DMABUF_SELFTESTS as part of the standard build for IGT, so
that they can be run by igt/dmabuf
Testcase: igt/dmabuf
Signed-off-by: Chris Wilson
Cc: Tomi Sarvela
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915
Use the %zu format specifier for a size_t returned by sizeo.
Reported-by: kbuild-...@01.org
Signed-off-by: Chris Wilson
---
drivers/dma-buf/st-dma-fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c
index
The dma-fence selftest uses an on-stack timer that requires explicit
annotation for debugobjects.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/dma-buf/st-dma-fence.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma
e_list(), which seems to be the
> only thing reserving buffers (in the ttm/dma_resv sense) in that
> code. So looks safe.
>
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> every
t; + }
> +
> + list_add_tail(&waiter->list, &cur->list);
> + return 0;
> + }
> + }
> +
> + list_add_tail(&waiter->list, &lock->wait_list);
> + return 0;
> +}
--
Chris Wilson, Intel Open Source Technology Centre
+ verbose_prune);
>
> This call to drm_mode_prune_invalid is probably just to paper over a bug
> in SNA - SNA violates the hotplug handling uabi by not unconditionally
> reprobing. Inconsistently paper over that bug in the kernel is not good,
> userspace interfaces need to be well defined. Please remove this call and
> test with either UXA or -modesetting until SNA is fixed.
This is not required for link retraining in userspace, since userspace's
response to seeing the link-status == BAD property is to retrain the
current mode (and then it checks link-status again to see if the modeset
worked because returning an error from the modeset seems troublesome).
After that it reprobes. However, the kernel must still fail the modeset
following link-status = BAD if it decides that the mode is no longer
valid.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ot good,
> userspace interfaces need to be well defined. Please remove this call and
> test with either UXA or -modesetting until SNA is fixed.
Then you should also categorically state that (once again) misusing the
HOTPLUG uevent for notification of a property update is wrong.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
igt/drm_mm
Fixes: 202b52b7fbf7 ("drm: Track drm_mm nodes with an interval tree")
Signed-off-by: Chris Wilson
Cc: David Herrmann
Cc: dri-devel at lists.freedesktop.org
Cc: Daniel Vetter
Cc: # v4.9-rc1+
---
drivers/gpu/drm/drm_mm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/
device->fops instead.
v2: Use C99 initializers to zero out unset elements of
dma_buf_export_info
v3: Extract the right module from dev->fops.
Testcase: igt/vgem_basic/unload
Reported-by: Petri Latvala
Signed-off-by: Chris Wilson
Cc: Petri Latvala
Cc: Christian König
Cc: sta
...);
close(dmabuf);
persists across module-unload as well as device closure.
Testcase: igt/vgem_basic/unload
Signed-off-by: Chris Wilson
Cc: Petri Latvala
---
drivers/gpu/drm/vgem/vgem_drv.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm
Suggested-by: Daniel Vetter
Signed-off-by: Chris Wilson
Cc: Petri Latvala
Cc: Daniel Vetter
Cc: stable at vger.kernel.org
Tested-by: Petri Latvala
---
drivers/gpu/drm/armada/armada_gem.c| 2 +-
drivers/gpu/drm/drm_prime.c| 30 +-
drivers/gpu/drm/i915
On Wed, Oct 05, 2016 at 03:11:00PM +0200, Daniel Vetter wrote:
> On Fri, Sep 30, 2016 at 02:59:59PM +0100, Chris Wilson wrote:
> > In order to keep the dmabuf alive whilst the mmap is, we need to hold a
> > reference to the dmabuf and not the backing object. This is important as
>
I hit send before completing a make htmldoc, and lo I forgot to fix up
the cut'n'paste.
Fixes: a4fce9cb782a ("drm/prime: Take a ref on the drm_dev when exporting...")
Reported-by: kbuild test robot
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: stable at vger.kernel.org
all these hardcoded values
> to PLANE_X, and convert "int"s  to "enum plane"s everywhere.
Note that this is not PLANE_A, but setting up a shorthand local for
const struct skl_plane_wm *p_wm = crtc_state->wm.skl.optimal.planes;
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
beneficial when the lifetime of the state becomes more
convoluted than being passed to a single worker thread for the commit.
v2: Double check !intel atomic_commit functions for missing gets
v3: Update kerneldocs
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
On Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
Plus equivalents in drm_plane.h, drm_encoder.h ...
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
fe5a66f91c88 ("drm/i915: Read PSR caps/intermediate freqs/etc. only
> once on eDP")
> Signed-off-by: Dan Carpenter
Oops, does smatch catch this? I don't recall seeing the complaint in
recent runs?
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
m_minor to drm_device
>
> Noticed by Chris Wilson.
>
> Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device")
> Cc: Chris Wilson
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Cc: Emil Velikov
> Cc: Julia Lawall
> Signed-off-by: Daniel Vetter
() itself with the bad block printing from
get_edid_block(), into a single warning associated with the connector
once all attempts to retrieve the EDID fail.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_edid.c | 82
active_list) {
> - if (fence_is_signaled_locked(&pt->base))
> + struct fence *fence = fence_get(&pt->base);
> + bool signaled;
> +
> + spin_unlock_irqrestore(&obj->child_list_lock, flags);
Hmm. The obj->chi
On Fri, Oct 14, 2016 at 01:46:37PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 13, 2016 at 08:43:55PM +0100, Chris Wilson wrote:
> > Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
> > intermediate edid reads. This causes transient failures in CI which
&
beneficial when the lifetime of the state becomes more
convoluted than being passed to a single worker thread for the commit.
v2: Double check !intel atomic_commit functions for missing gets
v3: Update kerneldocs
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
e been
by the caller). That spares us the issue of the flags being changed
here, and the changed flags not being propagated back.
We need only grab the list under the lock once, as once signaled no new
elements will be added to the list (after add_callback takes the lock it
checks for the signal).
i.e.
struct list_head cb_list;
list_splice_init(&fence->cb_list, &cb_list;
spin_unlock(fence->lock);
list_for_each_entry_safe(cur, tmp, &cb_list, node)
cur->func(fence, cur);
spin_lock(fence->lock);
Though I'm not convinced that dropping the lock is going to be safe for
everyone, since that lock may be communal and guarding move than just
the cb_list, e.g. virtio_gpu_fence_event_process().
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
since the fences put onto the wq
should be independent and can work in parallel. system_unbound should
suffice.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Sun, Oct 16, 2016 at 02:29:51PM -0400, Rob Clark wrote:
> On Sun, Oct 16, 2016 at 1:49 PM, Chris Wilson
> wrote:
> > On Sun, Oct 16, 2016 at 12:39:35PM -0400, Rob Clark wrote:
> >> This is the alternative approach for solving a deadlock situation with
> >> arr
501 - 600 of 3785 matches
Mail list logo
