If a driver does not have a parent, or never sets the unique name for
itself, then we may proceed to chase a NULL dereference through
debugfs/.../name.
Testcase: igt/vgem_basic/debugfs
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_info.c | 21 ++---
1
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 49e7ff9840bd..c3f177231f6a 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++
If a driver does not have a parent, or never sets the unique name for
itself, then we may proceed to chase a NULL dereference through
debugfs/.../name.
Testcase: igt/vgem_basic/debugfs
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_info.c | 21 ++---
1
---
drivers/gpu/drm/i915/i915_debugfs.c| 162 +---
drivers/gpu/drm/i915/i915_drv.h| 84 ++---
drivers/gpu/drm/i915/i915_gem.c| 144 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +-
drivers/gpu/drm/i915/i915_gem_request.c|
On Mon, Jun 20, 2016 at 09:04:32PM +0100, Chris Wilson wrote:
Eek, appologies. This was meant to git-send-email -v3 but mangled into
-3 instead.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
: With additional completeness.
v3: Need to clear the CPU cache upon exporting the dma-addresses.
Testcase: igt/vgem_basic/dmabuf-*
Testcase: igt/prime_vgem
Signed-off-by: Chris Wilson
Cc: Sean Paul
Cc: Zach Reizner
---
drivers/gpu/drm/vgem/vgem_drv.c | 112 +++-
1 file
ess, which should include waiting upon rendering.
(Some drivers may need to do more work to ensure that the dma-buf mmap
is coherent as well as complete.)
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro
A couple of drivers open-coded drm_connector_register_all() and so were
missed in my last pass. Also Emil pointed out that atmel-hlcdc also had
a redundant drm_connector_unregister_all() we could remove.
-Chris
drm_connector_unregister_all() is not automatically called by
drm_dev_unregister() so we can drop the local call.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Boris Brezillon
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 8
drm_dev_register() will now register all known connectors, so we no
longer have to do so manually.
Signed-off-by: Chris Wilson
Cc: Eric Anholt
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/vc4/vc4_drv.c | 12
1 file changed, 12
drm_dev_register() will now register all known connectors, so we no
longer have to do so manually.
Signed-off-by: Chris Wilson
Cc: Maxime Ripard
Cc: David Airlie
Cc: Chen-Yu Tsai
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel at lists.infradead.org
---
drivers
/* mode_config.mutex protects the connector list against e.g. DP MST
>* connector hot-adding. CRTC/Plane lists are invariant. */
> - mutex_lock(>mode_config.mutex);
And the comment needs removal.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
929,7 @@ int drm_mode_getresources(struct drm_device *dev, void
> *data,
> }
> copied++;
> }
> + connector_count = copied;
You forgot to actually make sure we don't copy more conectors than
planned.
-Chris
--
Chri
and connectors
> + */
> +void drm_modeset_unregister_all(struct drm_device *dev)
> +{
> + drm_plane_unregister_all(dev);
> + drm_crtc_unregister_all(dev);
> + drm_encoder_unregister_all(dev);
> + drm_connector_unregister_all(dev);
Unregister should be in the opposite order.
> +}
> +EXPORT_SYMBOL(drm_modeset_unregister_all);
I think the plan is not to export these symbols,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
k, since in the future num_connector is not guarded by mode_conf.mutex,
moving the read underneath that lock doesn't obviate the need for
READ_ONCE. Still it reduces the window and how far one has too look back
if it were set just before the connector loop.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
t; +
> + ret = drm_connector_register_all(dev);
> + if (ret)
> + goto err_connector;
> +
> + return 0;
> +
> +err_connector:
> + drm_encoder_unregister_all(dev);
The name here should be what we are about to free. That just makes it a
bit easier to change the sequence later (if adding new stags).
Looks good enough though,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ter_all
>
> version 4:
> move function definitions in drm_crtc_internal.h
> remove not needed documentation
>
> Signed-off-by: Benjamin Gaignard
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Sat, Jun 18, 2016 at 04:20:48PM +0100, Chris Wilson wrote:
> The vGEM mmap code has bitrotted slightly and now immediately BUGs.
> Since vGEM was last updated, there are new core GEM facilities to
> provide more common functions, so let's use those here.
Bugzilla: https://bugs.freede
readiness (i.e. this allows the user to schedule
operations out-of-order, but have them complete in-order).
This also makes it much easier to write tightly controlled testcases for
dma-buf fencing and signaling between hardware drivers.
Testcase: igt/vgem_basic/dmabuf-fence
Signed-off-by: Chris
We are only documenting that the read is outside of the lock, and do not
require strict ordering on the operation. In this case the more relaxed
lockless_dereference() will suffice.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Julia Lawall
Cc: Chris Wilson
Cc: Emil Velikov
---
drivers
call.
Testcase: igt/vgem_basic/mmap
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96603
Signed-off-by: Chris Wilson
Cc: Sean Paul
Cc: Zach Reizner
Cc: Matthew Auld
Tested-by: Humberto Israel Perez Rodriguez
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/vgem/vgem_drv.c | 164
: With additional completeness.
v3: Need to clear the CPU cache upon exporting the dma-addresses.
v4: Use drm_gem_put_pages() as well.
Testcase: igt/vgem_basic/dmabuf-*
Testcase: igt/prime_vgem
Signed-off-by: Chris Wilson
Cc: Sean Paul
Cc: Zach Reizner
---
drivers/gpu/drm/vgem/vgem_drv.c | 104
readiness (i.e. this allows the user to schedule
operations out-of-order, but have them complete in-order).
This also makes it much easier to write tightly controlled testcases for
dma-buf fencing and signaling between hardware drivers.
Testcase: igt/vgem_basic/dmabuf-fence
Signed-off-by: Chris
nces * sizeof(*fences), GFP_KERNEL);
> + if (!fences)
> + return NULL;
> +
> + memcpy(fences, array->fences, array->num_fences * sizeof(*fences));
> + return fences;
return kmemdup(array->fences,
array->num_fences * sizeof(*array->fences),
GFP_KERNEL);
--
Chris Wilson, Intel Open Source Technology Centre
, GFP_KERNEL);
The documentation should emphasize that the fences in the
returned array have a "borrowed" reference (i.e. it does not return a
new reference to each fence).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
new
function to run before the final fence_put().
would help, it is not until you use it in 5/5 that it becomes apparent
why it is needed.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_file->cbs[i].cb);
> - fence_put(sync_file->cbs[i].fence);
> - }
>
> + fence_remove_callback(sync_file->fence, _file->cb);
> + fence_teardown(sync_file->fence);
Hmm. Could we detect the removal of the last callback
In places (e.g. i915.ko), the alignment is exported to userspace as u64
and there now exists hardware for which we can indeed utilize a u64
alignment. As such, we need to keep 64bit integers throughout when
handling alignment.
Testcase: igt/gem_exec_alignment
Signed-off-by: Chris Wilson
= 0; i < bo_gem->softpin_target_count; i++) {
> + drm_intel_bo_gem *target_bo_gem = (drm_intel_bo_gem *)
> bo_gem->softpin_target[i];
> + drm_intel_gem_bo_unreference_locked_timed(_bo_gem->bo,
> time.tv_sec);
> + }
> + bo_gem->softpin_target_count = 0;
This would have better pursued using a batch manager.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
stop_machine() Kconfig dependency") removed the option STOP_MACHINE from
init/Kconfig and ensured that stop_machine() universally works.
Remove this now obsolete select statement.
> Signed-off-by: Andreas Ziegler
With a little bit of story correction,
Revieweed-by: Chris Wilson
-
if (fence_is_array(sync_file->fence)) {
> + struct fence_array *array = to_fence_array(sync_file->fence);
checkpatch will complain about the missing line between decl and code
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_fdget(fd);
> + if (!sync_file)
> + return NULL;
> +
> + fence = sync_file->fence;
> + fence_get(fence);
Or just fence = get_fence(sync_file->fence);
> + fput(sync_file->file);
Reviewed-by: Chris Wilson
Using fence-array for this works very nicely, as we can then inspect the
fences returned and handle native fences for fd passed around.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
imply as:
>
> pages = drm_gem_get_pages(obj);
> if (IS_ERR(pages))
> return ERR_CAST(pages);
>
> st = drm_prime_pages_to_sg(pages, n_pages);
> drm_gem_put_pages(obj, pages, false, false);
>
> return st;
That looks better, thanks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
so want to review
the handling of state/old_state to see if the same problem has cropped
up elsewhere.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
This effectively reverts
commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
Author: Chris Wilson
Date: Wed Jun 10 15:58:01 2015 +0100
drm: Avoid the double clflush on the last cache line in
drm_clflush_virt_range()
as we have observed issues with serialisation of the clflush operations
Just a quick resend of the existing vgem patches, all 3 have been acked,
but only the first 2 have reviews. The third involves both new ioctl and
dma-buf/fences, so perhaps people have been reluctant... But now is a
good time! These patches are exercised by intel-gpu-tools (or will be once
the new
call.
Testcase: igt/vgem_basic/mmap
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96603
Signed-off-by: Chris Wilson
Cc: Sean Paul
Cc: Zach Reizner
Cc: Matthew Auld
Tested-by: Humberto Israel Perez Rodriguez
Reviewed-by: Matthew Auld
Acked-by: Zach Reizner
---
drivers/gpu/drm/vgem
: With additional completeness.
v3: Need to clear the CPU cache upon exporting the dma-addresses.
v4: Use drm_gem_put_pages() as well.
v5: Use drm_prime_pages_to_sg()
Testcase: igt/vgem_basic/dmabuf-*
Testcase: igt/prime_vgem
Signed-off-by: Chris Wilson
Cc: Sean Paul
Cc: Zach Reizner
Acked-by: Zach Reizner
readiness (i.e. this allows the user to schedule
operations out-of-order, but have them complete in-order).
This also makes it much easier to write tightly controlled testcases for
dma-buf fencing and signaling between hardware drivers.
Testcase: igt/vgem_basic/dmabuf-fence
Signed-off-by: Chris
On Mon, Jul 11, 2016 at 12:10:40PM -0300, Gustavo Padovan wrote:
> 2016-07-11 Chris Wilson :
>
> > vGEM buffers are useful for passing data between software clients and
> > hardware renders. By allowing the user to create and attach fences to
> > the exported vGEM
to add an explicit fence back into the mix
of fences being tracked by the dma-buf allows that userspace fence to be
included in any implicit tracking.
Signed-off-by: Chris Wilson
Cc: Gustavo Padovan
Cc: Rob Clark
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
bmitted or not in this case?
It's insignificant. An actual error would result in a GPU hang, and
without being recorded in the error state any message here is useless.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Jul 12, 2016 at 12:44:17PM +0200, Daniel Vetter wrote:
> On Mon, Jul 11, 2016 at 04:24:45PM +0100, Chris Wilson wrote:
> > That doesn't fit the out-of-order unbound nature of the interface. The
> > interface is just a collection of fences that userspace associates with
= drm_gem_get_pages(obj);
>235if (IS_ERR(pages))
>236return NULL;
>237
> > 238addr = vmap(pages, n_pages, 0,
> pgprot_writecombine(PAGE_KERNEL_IO));
sparc64
I guess we need an ifdef PAGE_KERNEL_IO ?
or just rely on pgprot_writecombine(PAGE_KERNEL) being good enough
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
clared
>> (first use in this function)
addr = vmap(pages, n_pages, 0, pgprot_writecombine(PAGE_KERNEL_IO));
Reported-by: 0day
Fixes: e6f15b763ab2 ("drm/vgem: Enable dmabuf interface for export")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Daniel Vetter
---
drivers/gpu/drm/vge
On Tue, Jul 12, 2016 at 01:53:56PM +0200, Christian König wrote:
> Am 11.07.2016 um 23:59 schrieb Chris Wilson:
> >When dealing with user interfaces that utilize explicit fences, it is
> >convenient to sometimes create those fences after the fact, i.e. to
> >query the dma-bu
, but allocate
a separate fence-context for each fence so that the fences are
unordered.
Testcase: igt/vgem_basic/dmabuf-fence
Signed-off-by: Chris Wilson
Cc: Sean Paul
Cc: Zach Reizner
Cc: Gustavo Padovan
Cc: Daniel Vetter
Acked-by: Zach Reizner
---
drivers/gpu/drm/vgem/Makefile | 2
, we only want
to copy back the kernel arg data iff both the kernel and userspace
request the copy.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_ioctl.c | 50 -
1 file changed, 22 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm
On Wed, Jul 13, 2016 at 11:38:52AM +0200, Peter Zijlstra wrote:
> On Fri, Jun 24, 2016 at 10:08:46AM +0100, Chris Wilson wrote:
> > diff --git a/kernel/async.c b/kernel/async.c
> > index d2edd6efec56..d0bcb7cc4884 100644
> > --- a/kernel/async.c
> > +++ b/kernel
I plan to usurp the short name of struct fence for a core kernel struct,
and so I need to rename the specialised fence/timeline for DMA
operations to make room.
As an indication of the scale of the flag day:
91 files changed, 904 insertions(+), 880 deletions(-)
with the greatest victim being
On Wed, Jul 13, 2016 at 11:54:50PM +0900, Inki Dae wrote:
> Hi,
>
> 2016-07-13 23:10 GMT+09:00 Chris Wilson :
> > I plan to usurp the short name of struct fence for a core kernel struct,
> > and so I need to rename the specialised fence/timeline for DMA
> &
drm_connector_unregister_all() is automatically called by
drm_dev_unregister() and so the manual call can be dropped.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maxime Ripard
Cc: David Airlie
Cc: Chen-Yu Tsai
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel
-by: Chris Wilson
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_crtc.c | 29 +
include/drm/drm_crtc.h | 3 ---
2 files changed, 9 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers
his by delaying the drm_fb_helper_set_suspend call. Based on the
> i915 code (which was done for performance reasons though).
>
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Signed-off-by: Peter Wu
> ---
> Tested on top of v4.7-rc5, the deadlock is gone.
> ---
> dr
On Wed, Jul 13, 2016 at 10:56:58AM -0700, Sean Paul wrote:
> On Wed, Jul 13, 2016 at 9:39 AM, Chris Wilson
> wrote:
> > drm_connector_unregister_all() is automatically called by
> > drm_dev_unregister() and so the manual call can be dropped.
> >
eturn tmp & 1;
error:
DRM_ERROR("Failed to disable the SAGV\n");
return true;
}
ret = wait_for(sagv_disabled(dev_priv), 1);
if (ret)
DRM_ERROR("Timed out waiting for SAGV to be disabled\n");
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Jul 12, 2016 at 01:46:21PM +0100, Chris Wilson wrote:
> vGEM buffers are useful for passing data between software clients and
> hardware renders. By allowing the user to create and attach fences to
> the exported vGEM buffers (on the dma-buf), the user can implement a
> defer
led_eu)
> >+{
> >+drm_i915_getparam_t gp;
> >+int ret;
> >+
> >+memclear(gp);
> >+gp.value = (int*)has_pooled_eu;
> >+gp.param = I915_PARAM_HAS_POOLED_EU;
> >+ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
> >+if (ret)
On Wed, Jul 13, 2016 at 05:29:21PM -0300, Gustavo Padovan wrote:
> 2016-07-12 Chris Wilson :
>
> > vGEM buffers are useful for passing data between software clients and
> > hardware renders. By allowing the user to create and attach fences to
> > the exported vGEM
, but allocate
a separate fence-context for each fence so that the fences are
unordered.
v3: Make the debug output more interesting, and so the signaled status.
Testcase: igt/vgem_basic/dmabuf-fence
Signed-off-by: Chris Wilson
Cc: Sean Paul
Cc: Zach Reizner
Cc: Gustavo Padovan
Cc: Daniel Vetter
On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote:
> On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote:
> > vGEM buffers are useful for passing data between software clients and
> > hardware renders. By allowing the user to create and attach fences to
> &
On Thu, Jul 14, 2016 at 10:59:04AM +0100, Chris Wilson wrote:
> On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote:
> > On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote:
> > > vGEM buffers are useful for passing data between software clients and
>
On Thu, Jul 14, 2016 at 11:11:02AM +0100, Chris Wilson wrote:
> So one solution would be to make vgem fences automatically timeout (with
> a flag for root to override for the sake of testing hang detection).
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c
b/drivers/gpu/drm/vgem/vgem_fence.c
On Thu, Jul 14, 2016 at 02:40:59PM +0200, Daniel Vetter wrote:
> On Thu, Jul 14, 2016 at 11:11:02AM +0100, Chris Wilson wrote:
> > On Thu, Jul 14, 2016 at 10:59:04AM +0100, Chris Wilson wrote:
> > > On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote:
> > > &
On Thu, Jul 14, 2016 at 02:23:04PM +0100, Chris Wilson wrote:
> The biggest reason I had against going the sw_sync only route was that
> vgem should provide unprivileged fences and that through the bookkeeping
> in vgem we can keep them safe, ensure that we don't leak random buffers
&g
On Thu, Jul 14, 2016 at 04:36:37PM +0200, Daniel Vetter wrote:
> On Thu, Jul 14, 2016 at 02:39:54PM +0100, Chris Wilson wrote:
> > On Thu, Jul 14, 2016 at 02:23:04PM +0100, Chris Wilson wrote:
> > > The biggest reason I had against going the sw_sync only route was that
> &g
: igt/vgem_slow/nohang
Signed-off-by: Chris Wilson
Cc: Sean Paul
Cc: Zach Reizner
Cc: Gustavo Padovan
Cc: Daniel Vetter
Acked-by: Zach Reizner
---
drivers/gpu/drm/vgem/Makefile | 2 +-
drivers/gpu/drm/vgem/vgem_drv.c | 34 +
drivers/gpu/drm/vgem/vgem_drv.h | 16 +++
drivers/gpu
;
> > }
> >
> >+int
> >+drm_intel_get_pooled_eu(int fd)
> >+{
> >+drm_i915_getparam_t gp;
> >+int ret;
> >+
> >+memclear(gp);
> >+gp.param = I915_PARAM_HAS_POOLED_EU;
> >+gp.value =
> >+ret = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
> >+if (ret)
> >+return -errno;
Do I need to point out how the above is broken?
if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, ))
return -errno;
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Jul 15, 2016 at 01:26:22PM +0200, Peter Wu wrote:
> On Wed, Jul 13, 2016 at 06:17:47PM +0100, Chris Wilson wrote:
> > Hmm, since suspend_work can theorectically rearm itself, this should be
> > cancel_work_sync().
>
> How so? The worker calls with state =
On Fri, Jul 15, 2016 at 09:48:03PM +0200, Daniel Vetter wrote:
> Just replicates whether the list is empty or not. Nuke code
> to avoid writing docs for it!
>
> Cc: Dave Airlie
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
Unless Dave to planned to use it elsewher
ves (instead of
> what they point at) as const provides roughly 0 value. And it's confusing,
> since the data the pointer points at _is_ being changed.
It served its purpose of getting the compiler to sanity check that batch
was unchanged as we passed it around the various obscuration macros.
-Chris
On Fri, Jul 15, 2016 at 09:47:59PM +0200, Daniel Vetter wrote:
> Was forgotten when adding them all over. 0-day should complain about
> new missing kernel-doc, not sure why that wasn't caught/fixed.
>
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
> ---
> includ
Peter Zijlstra gave a lot of feedback and thanks to him, I think both
the function names and docs are a lot more sane. There is also a good
consensus on renaming dma-buf's struct fence to be struct dma_fence,
allowing for use of the cleaner name for the core struct.
A quick overview of a fence is
provides a building
block which can be used for determining an order in which tasks can
execute.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Shuah Khan
Cc: Tejun Heo
Cc: Daniel Vetter
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: "Paul E. McKenney"
A common requirement when scheduling a task is that it should be not be
begun until a certain point in time is passed (e.g.
queue_delayed_work()). kfence_await_hrtimer() causes the kfence to
asynchronously wait until after the appropriate time before being woken.
Signed-off-by: Chris Wilson
Cc
dma-buf provides an interfaces for receiving notifications from DMA
hardware, and for implicitly tracking fences used for rendering into
dma-buf. We want to be able to use these event sources along with kfence
for easy collection and combining with other events.
Signed-off-by: Chris Wilson
Cc
A preparatory patch for adding new features (and their tests). First we
want to add coverage of existing features to kselftest.
Signed-off-by: Chris Wilson
---
lib/Kconfig.debug | 9 ++
lib/Makefile| 1 +
lib/test-async-domain.c
scheme based upon
kfences and back every task with one. Any task may now wait upon the
kfence before being scheduled, and equally the kfence may be used to
wait on the task itself (rather than waiting on the cookie for all
previous tasks to be completed).
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
,
and async_dependency_get() retrieves a kfence for inspection or waiting
upon.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Shuah Khan
Cc: Tejun Heo
Cc: Daniel Vetter
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: "Paul E. McKenney"
Cc: Dan Williams
Cc: Andrey Ry
. not be scheduled) until all work queued before the
barrier is completed.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Shuah Khan
Cc: Tejun Heo
Cc: Daniel Vetter
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: "Paul E. McKenney"
Cc: Dan Williams
On Mon, Jul 18, 2016 at 09:15:35AM +0200, Daniel Vetter wrote:
> On Fri, Jul 15, 2016 at 09:06:04PM +0100, Chris Wilson wrote:
> > On Fri, Jul 15, 2016 at 09:47:59PM +0200, Daniel Vetter wrote:
> > > Was forgotten when adding them all over. 0-day should complain about
> >
mod_timer() takes an absolute jiffie value, not a relative timeout and
quietly fixup the missed ret=0 otherwise gcc just always returns that
the fence timed out.
Testcase: igt/vgem_basic/fence
Fixes: 407779848445 ("drm/vgem: Attach sw fences to exported vGEM dma-buf")
Signed-off-by: Ch
If we fail to create the anon file, we need to remember to release the
module reference on the owner.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc
le at it also improve/align the kerneldoc comment.
>
> v2: Mention where those ids are from ...
>
> Cc: Chris Wilson
> Cc: Maarten Lankhorst
> Acked-by: Chris Wilson
> Acked-by: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c
ngjun
Thanks,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
le at it also improve/align the kerneldoc comment.
>
> v2: Mention where those ids are from ...
>
> v3: Add -ing to supporting and try to not break the world.
>
> Cc: Chris Wilson
> Cc: Maarten Lankhorst
> Acked-by: Chris Wilson
> Acked-by: Maarten Lankhorst
&
n_crc/bad-rotation
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
y;
}
so that it is obvious that the plane takes precedence over the global
property when provided.
You've caught all the spots I can see so,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
em on SKL when we use the legay cursor plane
> as it only supports 0|180 whereas the universal planes support
> 0|90|180|270, and it will be a problem on CHV soon.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
s the wrong way.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
l place and use it everwhere.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
I didn't check for any other candidates though.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/Kconfig | 13 +
drivers/gpu/drm/vgem/vgem_fence.c | 14 --
include/uapi/drm/vgem_drm.h | 1 +
3 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
then used
> > to test implicit dma-buf fencing). This is regarded as a highly
> > dangerous feature and so hidden behind an expert config option and only
> > available to root when enabled.
--
Chris Wilson, Intel Open Source Technology Centre
mistakes creeping in, and assuming the patch is
complete:
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
rep leads
me to drm_primary_helper_update() which suggests no. Did I miss a
potential user controllable WARN->panic?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ate->src_y;
> + src->x2 = state->src_x + state->src_w;
> + src->y2 = state->src_y + state->src_h;
> +
> + dst->x1 = state->crtc_x;
> + dst->y1 = state->crtc_y;
> + dst->x2 = state->crtc_x + state->crtc_w;
> + dst->y2 = state->crtc_y + state->crtc_h;
It's a little surprising to me that the check writes fields into the
drm_plane_state. Care to at least mention the side-effects in the kernel
doc?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
filesystems) upon boot.
Fixes: 44adece57e26 ("drm/fb-helper: Add a dummy
remove_conflicting_framebuffers")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Tobias Jakobi
Cc: Noralf Trønnes
Cc: tomi.valkeinen at ti.com
Cc: dh.herrmann at gmail.com
Cc: Alex Deucher
---
include/drm/drm_f
@ void intel_dvo_init(struct drm_device *dev)
return;
}
- drm_encoder_cleanup(_encoder->base);
kfree(intel_dvo);
kfree(intel_connector);
}
--
Chris Wilson, Intel Open Source Technology Centre
RROR* pipe A underrun
Other than the annoying underrun, is everything else as expected? i.e.
no connected outputs? Have we lost dvo detection?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
1001 - 1100 of 3670 matches
Mail list logo
