@@ int drm_debugfs_cleanup(struct drm_minor *minor)
> static int connector_show(struct seq_file *m, void *data)
> {
> - seq_puts(m, status);
> + seq_puts(m, drm_get_connector_force_name(connector->force));
Loses the trailing '\n'. It's not required, but it loo
Indicate that the fence array will be signaled on the first completion
(signal-on-any mode) as opposed to waiting for all to be signaled.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Daniel Vetter
Cc: "Christian König"
---
drivers/dma-buf/dma-fence-a
the first in *that* set.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_request.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index
On Mon, Feb 20, 2017 at 01:32:42PM +0200, Joonas Lahtinen wrote:
> On pe, 2017-02-17 at 18:35 +0000, Chris Wilson wrote:
> > The code currently assumes that all fence arrays it sees are the normal
> > signal-on-all variety, and decomposes the array into its individual
> >
In a similar fashion to reservation_object_lock() and
reservation_object_unlock(), ww_mutex_trylock is also useful and so is
worth wrapping for consistency.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Joonas Lahtinen
Cc: Daniel Vetter
---
include/linux/reservation.h | 20
On Thu, Feb 23, 2017 at 12:07:17AM +, Colin King wrote:
> From: Colin Ian King
>
> trivial fix to spelling mistake in pr_err message
>
> Signed-off-by: Colin Ian King
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Te
upport BO freeing without dev->struct_mutex).
Reported-by: Robert Foss
Fixes: 9f0ba539d13ae (drm/gem: support BO freeing without dev->struct_mutex)
Signed-off-by: Chris Wilson
Cc: Robert Foss
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: Alex Deucher
Cc: Lucas Stach
Cc: stable at vge
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
on
nter_regs_len =
> + ARRAY_SIZE(b_counter_config_compute_basic);
> +
> + return 0;
> int
> i915_perf_register_sysfs_hsw(struct drm_i915_private *dev_priv)
> {
> @@ -178,9 +685,49 @@ i915_perf_register_sysfs_hsw(struct drm_i915_private
> *dev_priv)
> if (ret)
> goto error_render_basic;
> }
> + if (get_compute_basic_mux_config(dev_priv, &mux_len)) {
Why not use the derived state in dev_priv->perf.oa.mux_regs? Then we
only expose what is initialised.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
also depends upon us actually reseting the connector->status to
unknown in drm_mode_config_reset(), Daniel!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Nov 03, 2016 at 12:11:55PM -0400, Lyude Paul wrote:
> On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote:
> > On Thu, 2016-11-03 at 16:02 +0000, Chris Wilson wrote:
> > >
> > > On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote:
> > > >
&g
(fence);
int num_pending = atomic_read(&array->num_pending);
int i;
for (i = 0; i < array->num_fences; i++)
if (is_signaled(array->fences[i]) && !--num_pending) {
atomic_set(&array->num_pending, 0);
return false;
}
dma_fence_get(&array->base);
queue_work(system_unbound_wq, &array->enable_signaling_worker);
}
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Nov 03, 2016 at 07:34:02PM -0400, Rob Clark wrote:
> On Thu, Nov 3, 2016 at 5:41 PM, Chris Wilson
> wrote:
> > static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
> > {
> > struct dma_fence_array *array = to_dma_fence_array(fence);
>
m-intel/ #drm-intel-nightly contains one
interesting patch wrt to the partial vma->pages
https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next-queued&id=d2a84a76a3b970fa32e6eda3d85e7782f831379e
Do you mind testing -nightly to see if I'm barking up the wrong tree?
-Chris
--
Chr
/drm-intel/commit/?h=drm-intel-next-queued&id=d2a84a76a3b970fa32e6eda3d85e7782f831379e
>
> Do you want me to test this patch only on top of master? (If it applies!!!)
It won't apply directly, but you could try testing that commit and its
parent to see if my hunch was correct.
Thanks
osed to
the highest version). Since my guess was wrong, any clues you can find
to point me in the direction will be very useful.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
about these operations,
they are not included in the explicit fence they provide, at which point
we can't trust their fence to the exclusion of the implicit fences...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 10:35:08AM +0000, Chris Wilson wrote:
> > On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Hi,
> > >
0day found that stackdepot.h doesn't get automatically included on all
architectures, so remember to add our #include.
Reported-by: kbuild test robot
Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
-
On Tue, Nov 08, 2016 at 01:43:40PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 11:45:51AM +0000, Chris Wilson wrote:
> > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> > > &
On Tue, Nov 08, 2016 at 01:46:15PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 11:56:01AM +0000, Chris Wilson wrote:
> > 0day found that stackdepot.h doesn't get automatically included on all
> > architectures, so remember to add our #include.
> >
> >
DRM_DEBUG_MM is only valid if the DRM.ko is builtin as currently
depot_save_stack is not exported.
Fixes: 5c7fcf2db027 ("drm/i915: Enable drm_mm debug when enabling
DRM_I915_DEBUG")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 2 +-
1 file changed, 1 inser
Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 25e8e3793d29..d6ee0592b
f9 ("drm/i915: Queue the idling context switch after all
> other timelines")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
.c:(.text+0x16be82): undefined reference to `save_stack_trace'
Anyone got an idea for this one? m68k is missing save_stack_trace().
There's no arch CONFIG_HAS_SAVE_STACK_TRACE, it looks like an oversight
in arch/m68k.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
0day continues to complain about trying to save a stacktrace for the
users of the drm_mm range allocator. This time, it is that m68k has no
save_stack_trace(), which is apparently guarded by STACKTRACE_SUPPORT.
Make it depend so!
Reported-by: kbuild test robot
Signed-off-by: Chris Wilson
Cc
P.h
+++ b/include/drm/drmP.h
@@ -808,6 +808,7 @@ struct drm_device {
/** \name Locks */
/*@{ */
+ struct lock_class_key struct_mutex_class;
struct mutex struct_mutex; /**< For others */
struct mutex master_mutex; /**< For drm_minor::master and
On Thu, Nov 10, 2016 at 03:50:35PM +0200, Joonas Lahtinen wrote:
> Add 3 missing mutex_destroy to drm_dev_init teardown and
> drm_dev_release.
>
> v2:
> - Also include drm_dev_release
>
> Signed-off-by: Joonas Lahtinen
Reviewed-by: Chris Wilson
-Chris
--
Chris Wils
On Thu, Nov 10, 2016 at 03:36:34PM +0200, Joonas Lahtinen wrote:
> Update i915_driver_load kerneldoc to match code.
>
> Cc: Chris Wilson
> Signed-off-by: Joonas Lahtinen
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ocation.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Rob Clark
Cc: Ben Skeggs
Cc: Chunming Zhou
Cc: Ken Wang
Cc: Monk Liu
Cc
ing it back to the caller. (Note the fix only requires using
dma_fence_get_rcu() and correct handling, but we may as well use the
helper rather than inline equivalent code.)
Signed-off-by: Chris Wilson
Cc: Sumit Semwal seq);
+
+ if (!rcu_access_pointer(obj->fence_excl))
+ re
On Mon, Nov 14, 2016 at 11:55:40AM +, Chris Wilson wrote:
> The current code is subject to a race where we may try to acquire a
> reference on a stale fence:
>From i915.ko pov, this
Fixes: d07f0e59b2c7 ("drm/i915: Move GEM activity tracking into a common struct
reservation_o
ops when initializing fences.
> + */
> +extern const struct dma_fence_ops drm_crtc_fence_ops;
> +
> +static inline struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
> +{
> + BUG_ON(fence->ops != &drm_crtc_fence_ops);
> + return container_of(fence->lock, struct drm_crtc, fence_lock);
> +}
If you are planning to export this for use by drivers, you are missing
the EXPORT_SYMBOL(drm_crtc_fence_ops).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Nov 15, 2016 at 08:25:55AM +, Chris Wilson wrote:
> On Tue, Nov 15, 2016 at 10:57:35AM +0900, Gustavo Padovan wrote:
> > /**
> > + * dma_crtc_fence_ops - fence ops for the drm_crtc timeline
> > + *
> > + * It contains the dma_fence_ops that should
On Tue, Nov 15, 2016 at 05:42:35PM +0900, Gustavo Padovan wrote:
> 2016-11-15 Chris Wilson :
>
> > On Tue, Nov 15, 2016 at 10:57:35AM +0900, Gustavo Padovan wrote:
> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > index 11780a9..0870de1
; -
> /* Debugfs support */
> #if defined(CONFIG_DEBUG_FS)
> extern int drm_debugfs_create_files(const struct drm_info_list *files,
> @@ -1064,18 +779,6 @@ extern void drm_pci_free(struct drm_device *dev, struct
> drm_dma_handle * dmah);
> extern void drm_sysfs_hotplug_event(struct drm_device *dev);
>
>
> -struct drm_device *drm_dev_alloc(struct drm_driver *driver,
> - struct device *parent);
> -int drm_dev_init(struct drm_device *dev,
> - struct drm_driver *driver,
> - struct device *parent);
> -void drm_dev_ref(struct drm_device *dev);
> -void drm_dev_unref(struct drm_device *dev);
> -int drm_dev_register(struct drm_device *dev, unsigned long flags);
> -void drm_dev_unregister(struct drm_device *dev);
> -
> -struct drm_minor *drm_minor_acquire(unsigned int minor_id);
> -void drm_minor_release(struct drm_minor *minor);
>
> /*@}*/
>
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> new file mode 100644
> index ..98f930a76e6d
> --- /dev/null
> +++ b/include/drm/drm_drv.h
> @@ -0,0 +1,337 @@
> +/*
> + * Copyright 2016 Intel Corp.
Careful, it's a mix of some new and lots old. To be on the safe side, it
should retain all the copyright statements of the original.
Otherwise, pretty sure it was mechanical,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Mon, Nov 14, 2016 at 12:58:21PM +0100, Daniel Vetter wrote:
> Put the callback docs into struct drm_driver, and the small overview
> into a DOC comment.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
> +
> /* drm_dumb_buffers.c */
> +int drm_modeset_register_all(struct drm_device *dev);
> +void drm_modeset_unregister_all(struct drm_device *dev);
>
I was worried for a moment.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Mon, Nov 14, 2016 at 12:58:25PM +0100, Daniel Vetter wrote:
> Just noise.
>
> Signed-off-by: Daniel Vetter
Sometimes it is interesting. Practice across the kernel is mixed, but
convergence on not putting extern.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Op
On Mon, Nov 14, 2016 at 12:58:20PM +0100, Daniel Vetter wrote:
> Just cleans up what's there, still plenty missing.
>
> Signed-off-by: Daniel Vetter
I read it, seems to match my limited understanding of kerneldoc.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Sou
t;
> Fixes: d8187177b0b1 ("drm: add helper for printing to log or seq_file")
> Cc: Rob Clark
> Cc: Sean Paul
> Signed-off-by: Daniel Vetter
Oh well, I liked the practice of having interface descriptions in the
headers. If they are in the body, I may as well just read the
up and entirely
> documented.
>
> Signed-off-by: Daniel Vetter
Code motion looks ok, placement inside the rst I'll take you at your
word.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
mode_create_dumb_ioctl(struct drm_device *dev,
> +void *data, struct drm_file *file_priv);
> +int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
> + void *data, struct drm_file *file_priv);
> +int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
> + void *data, struct drm_file *file_priv);
> +
> /* drm_color_mgmt.c */
>
> /* IOCTLs */
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
> b/drivers/gpu/drm/drm_dumb_buffers.c
> new file mode 100644
> index ..4b4364b61c8d
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -0,0 +1,135 @@
> +/*
> + * Copyright (c) 2016 Intel Corporation
I've mentioned this elsewhere, but we should also retain the original
copyright statements for the code we are copying.
Otherwise,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
GNORE_DOCBOOKS=1 SPHINXOPTS=-W htmldocs" is that outdated?
I don't often run it since it is too slow when checking hundreds of
patches. Any chance of an incremental patch checker?
> Fixes: b42fe9ca0a1e ("drm/i915: Split out i915_vma.c")
> Cc: Tvrtko Ursulin
> Cc: Chris Wi
d1867005c ("dma-buf: Rename struct fence to dma_fence")
> Cc: Chris Wilson
> Cc: Gustavo Padovan
> Cc: Sumit Semwal
> Cc: Christian König
> Signed-off-by: Daniel Vetter
Weird, I caught some of the stale Documents/, obviously that didn't
trigger a warning that I ne
On Tue, Nov 15, 2016 at 12:47:31PM +0100, Daniel Vetter wrote:
> On Tue, Nov 15, 2016 at 10:42:08AM +0000, Chris Wilson wrote:
> > On Mon, Nov 14, 2016 at 12:58:16PM +0100, Daniel Vetter wrote:
> > > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
> > > b/drivers
Joonas complained that writing ww_mutex_lock(&resv->lock, ctx) was too
intrusive compared to reservation_object_lock(resv, ctx);
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Joonas Lahtinen
---
include/linux/reservation.h | 34 ++
1 file chan
- }
> - }
> -
> - e->base.fence = fence;
> -
> return e;
> }
>
> @@ -1793,6 +1809,165 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
> }
> EXPORT_SYMBOL(drm_atomic_clean_old_fb);
>
> +static struct dma_fence *get_crtc_fence(struct drm
Some clients would like to iterate over every node within a certain
range. Make a nice little macro for them to hide the mixing of the
rbtree search and linear walk.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_mm.c | 11
Some clients would like to iterate over every node within a certain
range. Make a nice little macro for them to hide the mixing of the
rbtree search and linear walk.
v2: Blurb
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_mm.c
il_slots) {
> + ret = -ENOSPC;
> + goto out;
> + }
You are not atomically reducing the mgr->avail_slots, leading to
possible overallocation of multiple streams?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, Jul 20, 2016 at 08:39:43PM +0100, Chris Wilson wrote:
> When performing driver testing, one factor we want to test is how we
> handle a foreign fence that is never signaled. We can wait on that fence
> indefinitely, in which case the driver appears hung, or we can take some
&
r now we will revert the change and enable signaling everytime time
> poll is called with timeout=0 as well.
>
> Cc: Chris Wilson
> Signed-off-by: Gustavo Padovan
Acked-by: Chris Wilson
I have some patches to use a bit on fence_array->flags to indicate where
we can use this shortcu
On Fri, Nov 18, 2016 at 10:40:02AM +0100, Daniel Vetter wrote:
> On Fri, Nov 18, 2016 at 08:49:37AM +0000, Chris Wilson wrote:
> > On Wed, Jul 20, 2016 at 08:39:43PM +0100, Chris Wilson wrote:
> > > When performing driver testing, one factor we want to test is how we
> >
ks it,
> depending in how fast I switch. (Yes, strange).
The fix should have landed in v4.9-rc5
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
l code.
For example it might be worth explaining why link_status is duplicated
on the connector and in its property (i.e. that is near impossible to
retrieve the value from the property).
> + connector->link_status = link_status;
> + drm_object_property_set_value(&connector->base,
> + dev->mode_config.link_status_property,
> + link_status);
> +}
> +EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
--
Chris Wilson, Intel Open Source Technology Centre
t;
> > > > Definitely need to document this properly in the property docs, no
> > > > matter
> > > > what we decide.
> > >
> > > Hmm. I think I kinda like this idea of userspace clear the state back
> > > to good explicitly, if it happens with the same prop. So it's like
> > > Maarten's retrain_link prop idea, but without having to add the second
> > > prop to the mix.
> > >
> > > It would also save me from pointing out (for the nth time) that the
> > > link status should really be cleared to good during the commit state
> > > swap and not at some random point during the commit ;)
> > >
> >
> > Okay, so change 1 is to make the userspace clear the state back to Good for
> > the property..
> > Then Change 2 is to set connector_changed flag in crtc_state to true if
> > this property changed
> > from BAD to GOOD. I am not quite how and where to change this to state
> > connector_changed to true.
> > Without this the full modeset will not happen and the whole design of
> > retrianing is lost.
>
> To make this work we need a few more bits:
>
> - link-status needs to become a full-blown atomic property. This means we
> need to move link_status into drm_connector_state, mark the property as
> type ATOMIC and wire up the get/set stuff.
>
> - once that's done it's also pretty easy to set crtc->connectors_changed
> from the atomic helpers. You can just compare old and new link_status in
> drm_connector_state, similar to how we compare old/new CRTC in
> drm_connector_state->crtc already.
>
> - Another fallout is that legacy clients will no longer see the
> link-status property. And they won't be able to set it through the
> SETCRTC ioctl, which would kinda defaut the point. I think the best
> solution would be to check for link_status == BAD in
> drm_atomic_helper_set_config, and reset it to good automatically for
> legacy clients.
Then how do they know that the kernel demands the modeset? Both a legacy
and atomic property?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Mon, Nov 21, 2016 at 11:00:52AM -0800, Manasi Navare wrote:
> On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 21, 2016 at 09:42:57AM +, Chris Wilson wrote:
> > > &
gt; >@@ -110,6 +110,7 @@ enum igt_atomic_crtc_properties {
> > IGT_CRTC_GAMMA_LUT,
> > IGT_CRTC_MODE_ID,
> > IGT_CRTC_ACTIVE,
> >+ IGT_CRTC_OUT_FENCE_PTR,
> > IGT_NUM_CRTC_PROPS
> >};
> >
> >@@ -298,6 +299,7 @@ struct igt_pipe {
> >
> > uint64_t mode_blob;
> > bool mode_changed;
> >+uint64_t out_fence_ptr;
>
> IMO this should be:
>
> int64_t *out_fence_ptr;
In userspace, fences are *fd*, a plain int. It is only the uabi that we
pass pointers as u64 to the kernel, and indeed that should be limited to
the uabi wrapper.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Nov 22, 2016 at 11:54:57AM +, Brian Starkey wrote:
> On Tue, Nov 22, 2016 at 11:06:00AM +0000, Chris Wilson wrote:
> >On Tue, Nov 22, 2016 at 10:53:51AM +, Brian Starkey wrote:
> >>Hi Gustavo,
> >>
> >>A little late to the party her
-by: Chris Wilson
---
drivers/gpu/drm/drm_fb_helper.c | 73 ++---
1 file changed, 40 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 14547817566d..d13c85682891 100644
--- a/drivers/gpu/
drm_fb_helper_probe_connector_modes() is always called before
drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a
small bit of code compaction.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_fb_helper.c | 37 +++--
1 file changed, 11
Though we only walk the kernel_fb_helper_list inside a panic (or single
thread debugging), we still need to protect the list manipulation on
creating/removing a framebuffer device in order to prevent list
corruption.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_fb_helper.c | 5 +
1
Some clients would like to iterate over every node within a certain
range. Make a nice little macro for them to hide the mixing of the
rbtree search and linear walk.
v2: Blurb
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Joonas Lahtinen
Use the color_adjust callback when reserving a node to check if
inserting a node into this hole requires any additional space, and so if
that space then conflicts with an existing allocation.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Reviewed-by
Silences
./include/drm/drm_drv.h:295: warning: Incorrect use of kernel-doc format
Signed-off-by: Chris Wilson
---
include/drm/drm_drv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index aad8bbacd1f0..52bf44e2b5cc 100644
--- a/include/drm
We are told not to set plane_state->fb directly, but use
drm_atomic_set_fb_for_plane() instead. Using the helper, means one less
piece of code that needs fixing should the interface change...
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 6 +-
1 file changed
it to the reference handling to prevent invalid use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/armada/armada_crtc.c| 9 +
drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
drivers/gpu/drm/drm_atomic.c| 44
In a couple of places currently, and with the intent to add more, we
update a pointer to a framebuffer to hold a new fb reference (evicting
the old).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_atomic.c | 8 ++--
include/drm/drm_framebuffer.h | 18 ++
2 files
ed start!
Fixes: 522e85dd8677 ("drm: Define drm_mm_for_each_node_in_range()")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
include/drm/drm_mm.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 6add455c651b.
A set of test cases to capture some annoying bugs and to ensure that
correct behaviour does not regress whilst fixing those!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/Kconfig | 13 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/test-drm_mm.c | 829
Build the struct drm_mm selftests so that we can trivially run them
within our CI.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index f0e769290e0b
Remove the ugly sparse casts by using the helper u64_to_user_ptr()
instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_property.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index
smatch correctly warns:
drivers/gpu/drm/drm_fb_helper.c:1960 drm_target_preferred() warn:
should '1 << i' be a 64 bit type?
drivers/gpu/drm/drm_fb_helper.c:2001 drm_target_preferred() warn:
should '1 << i' be a 64 bit type?
Signed-off-by: Ch
smatch warns:
drivers/gpu/drm/drm_lock.c:188 drm_legacy_lock() warn:
variable dereferenced before check 'master->lock.hw_lock' (see line 177)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_lock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/drm_mm.c | 37 +
include/drm/drm_mm.h | 16
2 files changed, 25 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 025dcd8cadcb
On Mon, Nov 28, 2016 at 08:55:58AM +0100, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 02:04:17PM +0000, Chris Wilson wrote:
> > Though we only walk the kernel_fb_helper_list inside a panic (or single
> > thread debugging), we still need to protect the list manipulation on
> &
On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> On Fri, Nov 25, 2016 at 03:32:31PM +0000, Chris Wilson wrote:
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1253,7 +1253,7 @@ drm_atomic_set_fb_for_plane(s
On Mon, Nov 28, 2016 at 03:15:12PM +0100, Daniel Vetter wrote:
> On Mon, Nov 28, 2016 at 08:46:11AM +0000, Chris Wilson wrote:
> > On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> > &
On Mon, Nov 28, 2016 at 08:26:07AM +0100, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 02:04:15PM +0000, Chris Wilson wrote:
> > +#define drm_fb_helper_for_each_connector(fbh, i__) \
> > + for (({lockdep_assert_held(&(fbh)->dev->mode_config.mutex); 1;}), \
> &g
ing the lockdep assertion inside the for(;;), I
anticipated an error that doesn't happen!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98826
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 73 ++---
1 file cha
Though we only walk the kernel_fb_helper_list inside a panic (or single
thread debugging), we still need to protect the list manipulation on
creating/removing a framebuffer device in order to prevent list
corruption.
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm
drm_fb_helper_probe_connector_modes() is always called before
drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a
small bit of code compaction.
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 37
On Tue, Nov 29, 2016 at 10:28:03AM -0500, Sean Paul wrote:
> On Tue, Nov 29, 2016 at 7:02 AM, Chris Wilson
> wrote:
> > drm_fb_helper_probe_connector_modes() is always called before
> > drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a
> > smal
On Tue, Nov 29, 2016 at 09:29:06PM +0100, Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 12:02:16PM +0000, Chris Wilson wrote:
> > drm_fb_helper_probe_connector_modes() is always called before
> > drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a
> > small b
Quoting Dan Carpenter (2017-06-14 10:14:52)
> These tests are reversed so it complains on every successful call and
> stays quiet for every failure. Also we may as well preserve the error
> code.
The test is correct. The expectation here is that i915_gem_object_ggtt_pin()
fails and reports ENOSPC
Quoting Rob Clark (2017-06-14 17:49:02)
> On Tue, Jun 13, 2017 at 6:52 PM, Sushmita Susheelendra
> wrote:
> > Buffer object specific resources like pages, domains, sg list
> > need not be protected with struct_mutex. They can be protected
> > with a buffer object level lock. This simplifies lockin
Quoting kbuild test robot (2017-06-15 16:23:12)
> drivers/gpu/drm/i915/i915_gem_execbuffer.c:300:2-7: WARNING: NULL check
> before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive
> or usb_free_urb is not needed. Maybe consider reorganizing relevant code to
> avoid passing
Quoting Daniel Vetter (2017-06-21 10:13:41)
> On Wed, Jun 21, 2017 at 04:34:20PM +1000, Nicholas Piggin wrote:
> > kbuild test robot found a build failure when building with thin
> > archives:
> >
> > http://marc.info/?l=linux-kbuild&m=149802285009737&w=2
> >
> > Signed-off-by: Nicholas Piggin
>
is desired -- but it will do for now.
Reported-by: Tomi Sarvela
Testcase: igt/gem_concurrent_blit/*swap*vgem*
Fixes: 5ba6c9ff961a ("drm/vgem: Fix mmaping")
Signed-off-by: Chris Wilson
Cc: Tomi Sarvela
Cc: Laura Abbott
Cc: Sean Paul
Cc: Matthew Auld
Cc: Daniel Vetter
Cc:
---
Quoting Chris Wilson (2017-06-22 14:30:08)
> static void *vgem_prime_vmap(struct drm_gem_object *obj)
> {
> + struct drm_vgem_gem_object *bo = to_vgem_bo(obj);
> long n_pages = obj->size >> PAGE_SHIFT;
> struct page **pages;
> void
is desired -- but it will do for now.
v2: also hold the pin across prime_vmap/vunmap
Reported-by: Tomi Sarvela
Testcase: igt/gem_concurrent_blit/*swap*vgem*
Fixes: 5ba6c9ff961a ("drm/vgem: Fix mmaping")
Signed-off-by: Chris Wilson
Cc: Tomi Sarvela
Cc: Laura Abbott
Cc: Sean Paul
Cc: Mat
Quoting Daniel Vetter (2017-06-23 12:02:53)
> On Thu, Jun 22, 2017 at 02:46:17PM +0100, Chris Wilson wrote:
> > + /* Flush the object from the CPU cache so that importers can rely
> > + * on coherent indirect access via the exported dma-address.
> > + */
> &
Quoting Christophe JAILLET (2017-06-27 06:38:54)
> 'dma_buf_vmap' returns NULL on error, not an error pointer.
>
> Fixes: 6cca22ede8a4 ("drm/i915: Add some mock tests for dmabuf interop")
> Signed-off-by: Christophe JAILLET
Thanks for the fix, reviewed and pushed.
-Chris
Quoting Sean Paul (2017-06-28 16:51:11)
> Protect against long-running processes from overflowing the timeline
> and creating fences that go back in time. While we're at it, avoid
> overflowing while we're incrementing the timeline.
>
> Signed-off-by: Sean Paul
> ---
> drivers/dma-buf/sw_sync.c
Quoting Sean Paul (2017-06-28 17:47:24)
> On Wed, Jun 28, 2017 at 05:00:20PM +0100, Chris Wilson wrote:
> > Quoting Sean Paul (2017-06-28 16:51:11)
> > > Protect against long-running processes from overflowing the timeline
> > > and creating fences that go back in tim
Quoting Sean Paul (2017-06-28 22:00:02)
> On Wed, Jun 28, 2017 at 08:45:55PM +0100, Chris Wilson wrote:
> > Quoting Sean Paul (2017-06-28 17:47:24)
> > > On Wed, Jun 28, 2017 at 05:00:20PM +0100, Chris Wilson wrote:
> > > > Quoting Sean Paul (2017-06-28 16:51:11)
If we know the context under which we are called, then we can use the
simpler form of spin_lock_irq (saving the save/restore).
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 15 +--
drivers/dma-buf/sync_debug.c
Use the canonical __dma_fence_is_later() to compare the fence seqno
against the timeline seqno to check if the fence is signaled.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 39 ++-
drivers/dma-buf/sync_debug.c | 9 -
drivers/dma-buf/sync_debug.h | 21 -
3 files changed, 26 insertions(+), 43
701 - 800 of 3785 matches
Mail list logo
