On Thu, Aug 04, 2016 at 11:50:27AM +0200, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 12:02:23PM +0300, Jani Nikula wrote:
> > On Tue, 12 Jul 2016, Daniel Vetter wrote:
> > > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote:
> > >> Backlights
unction return a struct fence pointer referencing the fence(s) in the
> Sync
> +File.
+ The returned reference is owned by the caller and must be disposed of
afterwards using fence_put(). In case of error, a NULL is returned
instead.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
k()
>
> v4: use user bit from fence flags (comment from Chris Wilson)
>
> Signed-off-by: Gustavo Padovan
> ---
> + if (!test_and_set_bit(POLL_ENABLED, _file->fence->flags)) {
> + if (fence_add_callback(sync_file->fence, _fil
On Fri, Aug 05, 2016 at 08:28:15AM +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 11:24:14PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Signalling doesn't need to be enabled at sync_file creation, it is only
> > required if userspace waiting
atus (as tracked by probe helpers)
> - anything in the edid changes (when setting it
> drm_mode_connector_update_edid_property)
> - other changes (like sink state changes in dpcd or whatever)
>
> That way userspace would be able to reliably spot such changes and do a
> new modeset.
Yes, please. I have had similar wishes for state changes and overall
modeset counters.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_helper]
> [1.356038] [] ? drm_modeset_unlock_all+0x66/0xc0 [drm]
> [1.356038] [] cirrus_fbdev_init+0xa0/0xb0 [cirrus]
> [1.356038] [] cirrus_modeset_init+0x18b/0x1e0 [cirrus]
> [1.356038] [] cirrus_driver_load+0xbc/0x100 [cirrus]
> [1.356038] [] drm_dev_register+0xa9/0xd0 [drm]
m/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -93,6 +93,6 @@ extern bool i915_gpu_turbo_disable(void);
> #defineI845_TSEG_SIZE_1M (3 << 1)
>
> #define INTEL_BSM 0x5c
> -#define INTEL_BSM_MASK (0x << 20)
> +#define INTEL_BSM_MASK (-(1u << 20))
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Alex Deucher
Cc: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu
check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Lucas Stach
Cc: Russell King <linux+etnaviv at armlinux.org.uk>
Cc: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff
check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index
check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 6cd4af443139
check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx
fence_get_rcu() that ensure that as
long as the seqlock is stable we hold the right references to the
fences.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Christian König
Cc: Alex Deucher
Cc: Sumit Semwal
---
drivers/dma-buf/reservation.c | 73
and then searching for the relevant pin later.
v2: Joonas' stylistic nitpicks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 60 ++--
drivers/gpu/drm/i915/i915_gem.c| 225 +++--
drivers
where we are discarding the full VMA offset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 6 +++---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem.c| 6 +++---
drivers/gpu/drm/i915/i915_gem_context.c| 6
section does not prevent this reallocation, instead
we have to inspect the reservation's seqlock to double check if the
fences have been reassigned as we were acquiring our reference.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Christian König
Cc: Alex Deucher
Cc
section does not prevent this reallocation, instead
we have to inspect the reservation's seqlock to double check if the
fences have been reassigned as we were acquiring our reference.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Christian König
Cc: Alex Deucher
Cc
Apologies, please ignore these 2. Didn't pass the right start point to
git-send-email.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Aug 11, 2016 at 11:19:50PM +0530, Sumit Semwal wrote:
> Hi Chris,
>
> On 11 August 2016 at 20:16, Chris Wilson wrote:
> > Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> > timeout of 0 becomes reservation_object_test_signaled_rcu(), we do n
-by: Chris Wilson
Cc: Daniel Vetter
Cc: Sumit Semwal
---
include/linux/fence.h | 51 ++-
1 file changed, 46 insertions(+), 5 deletions(-)
diff --git a/include/linux/fence.h b/include/linux/fence.h
index 5f50ab273c38..e93f7e70d0fe 100644
--- a/include
sages would have better conformity, especially between our messages
and those printed by subsystems on our behalf (using our struct device).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
;
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2:
> - Use dev_printk for the dev variant (Chris Wilson)
>
>
> drivers/gpu/drm/drm_drv.c | 31 +--
> include/drm/drmP.h| 133
> --
>
On Fri, Aug 12, 2016 at 09:26:32PM +0200, Lukas Wunner wrote:
> On Fri, Aug 12, 2016 at 07:39:38PM +0100, Chris Wilson wrote:
> > On Fri, Aug 12, 2016 at 01:30:00PM -0400, Sean Paul wrote:
> > > This patch consolidates all the various log functions/macros into
> > >
iple devices of the same type.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2:
> - Use dev_printk for the dev variant (Chris Wilson)
>
> Changes in v3:
> - Rename drm_log to drm_dev_printk (Chris Wilson)
> - Break out drm_printk from drm_dev_p
loff_t *ppos)
> +{
> + struct i915_perf_read_state state = { count, 0, buf };
> + int ret = stream->ops->read(stream, );
> +
> + /* If we've successfully copied any data then reporting that
> + * takes precedence over any internal error status, so the
> + * data isn't lost
> + */
> + return state.read ? state.read : (ret ? ret : -EAGAIN);
return state.read ?: ret ?: -EAGAIN;
Alternatively you could follow the standard pattern for read. Dare I ask
what is going to go into state that needs the obfuscation?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
d is invalid.
>
> The distinction makes the difference between allowing the buffer to be
> executed as an unprivileged batch buffer or returning an EINVAL error to
> userspace without executing anything.
Ah, but you choose to actually execute it instead. We can't allow that
either.
-Chris
--
igt/prime_vgem
Testcase: igt/gem_concurrent_blit # *vgem*
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: linux-kernel at vger.kernel.org
---
driv
tune them appropriately to benefit
everyone.
Signed-off-by: Chris Wilson
Cc: fritsch at kodi.tv
Cc: Deepak S
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_pm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/in
Apolgies, I changed trees between resending after the first git-send-email
bounced off the wrong address.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
igt/prime_vgem
Testcase: igt/gem_concurrent_blit # *vgem*
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: linux-kernel at vger.kernel.org
---
driv
;ggtt_alignment,
> + 0);
> + if (ret)
> + return ret;
> +
> + i915_oa_legacy_context_pin_notify(dev_priv, ctx);
> +
> + return 0;
> +}
I am still not all at all happy with this. I hope the recent changes to
do the vma tracking make it clear.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 16, 2016 at 03:59:24PM +0100, Robert Bragg wrote:
>On Mon, Aug 15, 2016 at 3:57 PM, Chris Wilson
> Alternatively you could follow the standard pattern for read. Dare I ask
> what is going to go into state that needs the obfuscation?
>
>I had dug arou
The drivers have to modify the atomic plane state during the prepare_fb
callback so they track allocations, reservations and dependencies for
this atomic operation involving this fb. In particular, how else do we
set the plane->fence from the framebuffer!
Signed-off-by: Chris Wilson
Cc: Dan
Now that we subclass our request from struct fence, we start using the
common primitives more freely and so avoid hand-rolling routines already
provided for by the helpers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 3 --
drivers/gpu/drm/i915/intel_display.c
Since dev_printk likes to print "(NULL device *):" when passed in a NULL
pointer, we have to manually call printk() ourselves.
Fixes: c4e68a583202 ("drm: Introduce DRM_DEV_* log messages")
Signed-off-by: Chris Wilson
Cc: Eric Engestrom
Cc: Sean Paul
---
drivers/g
mutex_lock(_priv->perf.lock);
> +
> + dev_priv->perf.metrics_kobj =
> + kobject_create_and_add("metrics",
> + _priv->drm.primary->kdev->kobj);
> + if (!dev_priv->perf.metrics_kobj)
> + goto exit;
> +
> + if (i915_perf_init_sysfs_hsw(dev_priv)) {
If you say hsw only, I expect to see a local check or comment saying we
are on Haswell.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
gt;
> Reported-by: Alexander Potapenko
> Cc: Alexander Potapenko
> Cc: stable at vger.kernel.org
> Signed-off-by: Daniel Vetter
That explains the oops.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
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
ompute_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, _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
ually 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:
> > > >
if (is_signaled(array->fences[i]) && !--num_pending) {
atomic_set(>num_pending, 0);
return false;
}
dma_fence_get(>base);
queue_work(system_unbound_wq, >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=d2a84a76a3b970fa32e6eda3d85e7782f831379e
Do you mind testing -nightly to see if I'm barking up the wrong tree?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
/drm-intel/commit/?h=drm-intel-next-queued=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,
-Chris
e 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
t 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
---
d
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.
> >
> > Rep
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
fined 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
/** \name Locks */
/*@{ */
+ struct lock_class_key struct_mutex_class;
struct mutex struct_mutex; /**< For others */
struct mutex master_mutex; /**< For drm_minor::master and
drm_file::is_master */
/*@} */
to test for a false positive
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 <linux+etnaviv at armlinux.org.uk>
Cc: Christian Gmeiner
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Rob Clark
Cc: Ben Skeggs
Cc: Chunm
urning 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
nitializing 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 != _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 Source T
gt; 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 code.
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
uct 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 Wilson
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 needed
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(>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 changed, 34 inserti
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_crtc *crtc)
> +{
return drm_crtc_fence_create(crtc);
(or possibly, drm_crtc_fence_get(), drm_crtc_timeline_advance() or
somesuch if we need finer control over fence_seqno)
Or if you want to embed it,
struct our_fence *fence;
fence = kzalloc(sizeof(*fence), GFP_KERNEL);
if (!fence)
return NULL;
drm_crtc_fence_init(crtc, >base);
return >base;
Looks tidier than dumping all the fence construction here
> + dma_fence_init(fence, _crtc_fence_ops, >fence_lock,
> +crtc->fence_context, ++crtc->fence_seqno);
--
Chris Wilson, Intel Open Source Technology Centre
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
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
&
; For 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
plaining 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(>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
finitely 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:
> > > &
@@ -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
off-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
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
801 - 900 of 3670 matches
Mail list logo
