> + ret = -EFAULT;
> + goto err_free_handles;
> + }
> +
> + fences = kcalloc(args->count_handles,
> + sizeof(struct dma_fence *), GFP_KERNEL);
if (!fences) /* blah */
> +
> + for (i = 0; i < args->count_
> This should only be used to interact with sync files where necessary.
>
> v1.1: fence put fixes (Chris), drop fence from ioctl names (Chris)
> fixup for new fence replace API.
>
> Reviewed-by: Sean Paul
> Signed-off-by: Dave Airlie
Reviewed-by: Chris Wilson
-Chris
--
Chr
es drm_unplug_dev by not only reverting
> commit a39be606f99d ("drm: Do a full device unregister when unplugging")
> but by also adding a call to drm_modeset_unregister_all before the
> drm_minor_unregister calls to make sure all sysfs entries are removed
> before calling dev
On Thu, Jun 01, 2017 at 02:13:28PM +0200, Hans de Goede wrote:
> Hi,
>
> On 31-05-17 04:39, jeffy wrote:
> >Hi Hans,
> >
> >thanx for investigating :)
> >
> >On 05/30/2017 03:06 PM, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 29-0
Daniel started a crusade a few years back to move control over the
initialisation and teardown into the driver rather than drm core, for
greater control and far fewer surprises. Help in that fight by adding
compiler warnings to the stale functions.
Signed-off-by: Chris Wilson
---
This is not as
On Thu, Jun 01, 2017 at 02:26:01PM +0200, Hans de Goede wrote:
> Hi,
>
> On 01-06-17 14:22, Chris Wilson wrote:
> >On Thu, Jun 01, 2017 at 02:13:28PM +0200, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 31-05-17 04:39, jeffy wrote:
> >>>Hi Hans,
On Fri, Oct 21, 2016 at 02:45:41PM +0200, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 10:14:21AM +0100, Chris Wilson wrote:
> > If we know which connector was plugged/unplugged or
> > connected/disconnected, we can pass that information along to userspace
> > inside the
drm_mode_dirtyfb_ioctl(struct drm_device *dev,
}
if (num_clips && clips_ptr) {
+ int i;
+
if (num_clips < 0 || num_clips > DRM_MODE_FB_DIRTY_MAX_CLIPS) {
ret = -EINVAL;
goto out_err1;
}
+
clips = kcalloc(num_clips, sizeof(*clips), GFP_KERNEL);
if (!clips) {
ret = -ENOMEM;
@@ -520,6 +523,14 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
ret = -EFAULT;
goto out_err2;
}
+
+ for (i = 0; i < num_clips; i++) {
+ if (clips[i].x2 < clips[i].x1 ||
+ clips[i].y2 < clips[i].y1) {
+ ret = -EINVAL;
+ goto out_err2;
+ }
+ }
}
if (fb->funcs->dirty)
--
Chris Wilson, Intel Open Source Technology Centre
good position to know which outputs need to be reprobed (since
it has just responded to the hardware notification) and can convey this
information to userspace by tracking the timestamp of the last connector
change onto the GETCONNECTOR query.
Signed-off-by: Chris Wilson
---
Adding an epoch
integer overflow:
[ 48.728503] 2240 * 100 cannot be represented in type 'int'
Reported-by: Martin Liška
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98372
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_modes.c | 8 ++--
1 file changed, 6 insertions(+), 2
On Fri, Oct 21, 2016 at 08:19:03PM +0200, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 01:57:28PM +0100, Chris Wilson wrote:
> > I think of a use for sending an empty clip: where you don't want to
> > push any new pixel data, but you do want to be sure that the pipeline
return the
garbage. Not only should we fix the error handling here, but you also
need to fix the error handling in drivers/video/backlight/backlight.c as
despite many callees returning an error, it assumes that
bd->ops->get_brightness() never returns an error...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
the valid extensions.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_edid.c | 78 --
1 file changed, 55 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers
On Mon, Oct 24, 2016 at 12:33:41PM +0100, Chris Wilson wrote:
> for (j = 1; j <= edid[0x7e]; j++) {
> - u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH;
> + u8 *block = edid + j * EDID_LENGTH;
>
> fo
the valid extensions.
v3: Fix invalid/valid extension fumble.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 79 --
1 file changed, 56 insertions(+), 23
On Mon, Oct 24, 2016 at 03:57:10PM -0400, Rob Clark wrote:
> Signed-off-by: Rob Clark
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
during drm_atomic_helper_legacy_gamma_set().
Based on a patch by Felix Monninger
Reported-by: Felix Monninger
References: https://bugs.freedesktop.org/show_bug.cgi?id=98420
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_atomic.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions
=98420
Signed-off-by: Felix Monninger
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_atomic.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1b5a32df9a9a..e0760c138355 100644
--- a/drivers/gpu/drm
On Tue, Oct 25, 2016 at 05:27:21PM -0400, Sean Paul wrote:
> On Tue, Oct 25, 2016 at 3:46 PM, Chris Wilson
> wrote:
> > drm_property_lookup_blob() returns a reference to the returned blob, and
> > drm_atomic_replace_property_blob() takes a references to the blob it
> >
i915_perf_open_ioctl_locked(struct drm_i915_private
> *dev_priv,
> + /* we avoid simply assigning stream->sample_flags = props->sample_flags
> + * to have _stream_init check the combination of sample flags more
> + * thoroughly, but still this is the expected result at this point.
>*/
> - DRM_ERROR("Unsupported i915 perf stream configuration\n");
> - ret = -EINVAL;
> - goto err_alloc;
> + BUG_ON(stream->sample_flags != props->sample_flags);
if (WARN_ON(...)) {
ret = -ENODEV;
goto err_alloc;
}
just to avoid checkpatch complaining.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, Oct 26, 2016 at 12:05:44AM +0100, Chris Wilson wrote:
> On Tue, Oct 25, 2016 at 12:19:29AM +0100, Robert Bragg wrote:
> > + /* So that we don't have to worry about updating the context ID
> > +* in OACONTOL on the fly we make sure to pin the context
> &
|
- trace_fence_emit
+ trace_dma_fence_emit
|
- FENCE_TRACE
+ DMA_FENCE_TRACE
|
- FENCE_WARN
+ DMA_FENCE_WARN
|
- FENCE_ERR
+ DMA_FENCE_ERR
)
(
...
)
Signed-off-by: Chris Wilson
Reviewed-by: Gustavo Padovan
Acked-by: Sumit Semwal
Acked-by: Christian König
---
Documentation/sync_file.txt
+ dma_fence_is_array
|
- trace_fence_emit
+ trace_dma_fence_emit
|
- FENCE_TRACE
+ DMA_FENCE_TRACE
|
- FENCE_WARN
+ DMA_FENCE_WARN
|
- FENCE_ERR
+ DMA_FENCE_ERR
)
(
...
)
Signed-off-by: Chris Wilson
Reviewed-by: Gustavo Padovan
Acked-by: Sumit Semwal
Acked-by: Christian König
+ DMA_FENCE_TRACE
|
- FENCE_WARN
+ DMA_FENCE_WARN
|
- FENCE_ERR
+ DMA_FENCE_ERR
)
(
...
)
Signed-off-by: Chris Wilson
Reviewed-by: Gustavo Padovan
Acked-by: Sumit Semwal
Acked-by: Christian König
---
Documentation/sync_file.txt| 8 +-
drivers/base/Kconfig
.
When we report to userspace, we convert the timeout into an error,
usually EBUSY or ETIME. Applying that same convention here makes this
all much cleaner...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
mmetry, keeping the vma you pinned and unpinning the same
later makes its ownership much clearer. (And I do want the owner of each
pin to be clear, for when we start enabling debug to catch the VMA
leaks.)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
en if there have not been any changes in the mode list
> > or connector status.
> >
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Cc: Ville Syrjala
> > Cc: Chris Wilson
> > Signed-off-by: Manasi Navar
for this idea was that this could serve as the
failure notification path for nonblocking modesets (well modesets in
general since it appears returning the error is not going to happen).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
> Cc: Carlos Santa
> Cc: Kirill A. Shutemov
> Tested-by: Carlos Santa
> Tested-by: Kirill A. Shutemov
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
; + drm_connector_unreference(modeset->connectors[j]);
> + modeset->connectors[j] = NULL;
> + }
> +
Don't we also need a similar cleanup loop in drm_fb_helper_crtc_free()?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, Oct 26, 2016 at 02:17:16PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote:
> > On Wed, 26 Oct 2016, Chris Wilson wrote:
> > > On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel Vetter wrote:
> > >> I'd go fur
On Wed, Oct 26, 2016 at 04:15:39PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 26, 2016 at 02:11:00PM +0100, Chris Wilson wrote:
> > On Wed, Oct 26, 2016 at 02:17:16PM +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote:
> >
ut for now I just slapped on a FIXME.
>
> v2: Cleanup things drm_fb_helper_crtc_free() too (Chris)
>
> Cc: Chris Wilson
> Cc: stable at vger.kernel.org
> Cc: Carlos Santa
> Cc: Kirill A. Shutemov
> Tested-by: Carlos Santa (v1)
> Tested-by: Kirill A. Shutemov (v1)
>
rrect reference accounting.
>
> Signed-off-by: Gustavo Padovan
Fixes: 30cd85dd6edc ("dma-buf/sync_file: hold reference to fence when creating
sync_file")
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
We can use the kernel's stack tracer and depot to record the allocation
site of every drm_mm user and then on shutdown as well as warning that
allocated nodes still reside with the drm_mm range manager, we can also
display who allocated them to aide tracking down the leak.
Signed-off-by:
A frequent issue that arises on shutdown is the drm_mm range manager
complaining of a leak. To aide debugging those, drm can now track the
allocation callsite and print those for the leaks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion
so it lies underneath the DRM options submenu.
Signed-off-by: Chris Wilson
Reviewed-by: Christian König
---
drivers/gpu/drm/Kconfig | 13 +
drivers/gpu/drm/drm_mm.c | 74 ++--
include/drm/drm_mm.h | 6
3 files changed, 90 insertions(
name, int fd1, int fd2)
> +{
> + struct sync_merge_data data = {};
> + int err;
What I liked was doing
if (fd2 < 0)
return dup(fd1);
if (fd1 < 0)
return dup(fd2);
That makes accumulating the fences in the caller much easier (i.e. they
start with
batch.fence_in = -1;
then
batch.fence_in = sync_merge(batch.fence_in, fence);
finished by
execbuf(&batch);
close(batch.fence_in);
batch.fence_in = -1;
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Mon, Oct 31, 2016 at 10:30:23AM -0400, Rob Clark wrote:
> On Mon, Oct 31, 2016 at 9:55 AM, Chris Wilson
> wrote:
> > What I liked was doing
> >
> > if (fd2 < 0)
> > return dup(fd1);
> >
> > if (fd1 < 0)
> > return dup(f
On Mon, Oct 31, 2016 at 10:57:16AM -0400, Rob Clark wrote:
> On Mon, Oct 31, 2016 at 10:38 AM, Chris Wilson
> wrote:
> > Which discards the synchronisation on the new fence if there's an error,
> > are we meant to flag a GL_ERROR?
>
> The error checking should alr
int fd)
> + *{
> + * if (sync_accumulate("foo", &batch.fence_fd, fd)) {
> + * ... error ...
> + * }
> + *}
> + */
> +static inline int sync_accumulate(const char *name, int *fd1, int fd2)
> +{
> + int ret;
> +
> + assert(fd2 >= 0);
> +
> + if (*fd1 < 0) {
> + *fd1 = dup(fd2);
> + return 0;
> + }
> +
> + ret = sync_merge(name, *fd1, fd2);
> + if (ret < 0) {
> + /* leave *fd1 as it is */
> + return ret;
> + }
> +
> + close(*fd1);
> + *fd1 = ret;
> +
> + return 0;
> +}
Lgtm, matches how we want to use it.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
If the fence context has notifies enabled, each of the fences'
FENCE_FLAG_SIGNALED_BIT will be updated from the interrupt. We can rely
on this status for reporting the current fence_is_signaled() and so
avoid an expensive uncached read.
Signed-off-by: Chris Wilson
Cc: Ben Skeggs
Cc: dri-
On Wed, Sep 07, 2016 at 09:21:05PM +0100, Chris Wilson wrote:
> If the fence context has notifies enabled, each of the fences'
> FENCE_FLAG_SIGNALED_BIT will be updated from the interrupt. We can rely
> on this status for reporting the current fence_is_signaled() and so
> a
ng.
No. Fix the root cause as this affects not just flips but copies -
this implies that everybody using the resv object must wait for all
fences. The resv object is not just used for prime, but all fencing, so
this breaks the ability to schedule parallel operations across engine.
-Chris
--
Chris W
; mutex_lock(&item->mutex);
> if (item->refcount == 0) {
> - item->object = kzalloc(ref->size, GFP_KERNEL);
> - if (unlikely(item->object == NULL)) {
> + ref->object = kzalloc(ref->size, GFP_KERNEL);
So the item
On Thu, Sep 08, 2016 at 03:22:48PM +0800, Huang Rui wrote:
> On Thu, Sep 08, 2016 at 02:36:06PM +0800, Chris Wilson wrote:
> > On Wed, Sep 07, 2016 at 10:07:57PM -0400, Huang Rui wrote:
> > > In previous drm_global_item_ref, there are two times of writing
> > > ref->
On Thu, Sep 08, 2016 at 09:43:52AM +0200, Christian König wrote:
> Am 08.09.2016 um 09:35 schrieb Chris Wilson:
> >On Thu, Sep 08, 2016 at 03:22:48PM +0800, Huang Rui wrote:
> >>On Thu, Sep 08, 2016 at 02:36:06PM +0800, Chris Wilson wrote:
> >>>On Wed, Sep 07, 2016
On Thu, Sep 08, 2016 at 05:21:42PM +0200, Mario Kleiner wrote:
> On 09/08/2016 08:30 AM, Chris Wilson wrote:
> >On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote:
> >>amdgpu-kms uses shared fences for its prime exported dmabufs,
> >>instead of an exclusive
On Tue, Sep 13, 2016 at 10:44:11AM +0200, Christian König wrote:
> Am 09.09.2016 um 03:15 schrieb Michel Dänzer:
> >On 09/09/16 01:23 AM, Chris Wilson wrote:
> >>On Thu, Sep 08, 2016 at 05:21:42PM +0200, Mario Kleiner wrote:
> >>>On 09/08/2016 08:30 AM, Chris Wils
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
fences[i++] = fence_get(a_fences[0]);
That ensures the sync_file inherits the signaled status without having
to keep all fences.
I think there still seems to be a memory leak when calling
sync_file_set_fence() here with i == 1.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
as delme, kernel log as delme2. Nothing too
> suspicious :-(.
[ 234.547] (EE) intel(0): failed to set mode: Permission denied
upon resume.
There is a VT switch so there should be a DropMaster, SetMaster combo
across resume, but that didn't flag any errors. I couldn't see any sign
of logi
On Wed, Sep 14, 2016 at 11:04:01AM -0300, Gustavo Padovan wrote:
> 2016-09-14 Chris Wilson :
> > I think there still seems to be a memory leak when calling
> > sync_file_set_fence() here with i == 1.
>
> I think that is something we discussed already, we don't hold an ex
al expired fence's refcount go to zero.
>
Testcase: igt/sw_sync/...?
> Signed-off-by: Rafael Antognolli
Lgtm,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
struct intel_engine_cs *engine)
> {
> - int ret;
> -
> - ret = intel_engine_init_breadcrumbs(engine);
> - if (ret)
> - return ret;
> -
> - return 0;
> + return intel_engine_init_breadcrumbs(engine);
These are written like this for consistency and ease of change.
-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 Wed, Sep 21, 2016 at 10:26:25AM +0300, Gustavo Padovan wrote:
> Hi Rafael,
>
> 2016-09-14 Rafael Antognolli :
>
> > Hi Chris and Gustavo,
> >
> > On Mon, Aug 29, 2016 at 07:16:13PM +0100, Chris Wilson wrote:
> > > If we being polled with a timeout of z
_array is not created instead we just assigned the
> fence to sync_file->fence. Then we do not use the fences array anymore nor
> does free it.
>
> This patch frees the array.
>
> Signed-off-by: Gustavo Padovan
> Reported-by: Chris Wilson
> ---
> drivers/dma-b
!).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94631
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_prime.c | 94 +++--
include/drm/drmP.h | 5 ++-
2 files changed, 77 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm
On Fri, Sep 23, 2016 at 03:49:26PM +0200, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 08:08:33AM +0100, Chris Wilson wrote:
> > With the seqlock now extended to cover the lookup of the fence and its
> > testing, we can perform that testing solely under the seqlock guard an
On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote:
> > Currently we install a callback for performing poll on a dma-buf,
> > irrespective of the timeout. This involves taking a spinlock, as well as
>
On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote:
> > Currently we install a callback for performing poll on a dma-buf,
> > irrespective of the timeout. This involves taking a spinlock, as well as
>
On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote:
> > Currently we install a callback for performing poll on a dma-buf,
> > irrespective of the timeout. This involves taking a spinlock, as well as
>
rt part?
Adding and propagating:
diff --git a/include/linux/fence.h b/include/linux/fence.h
index 0d763053f97a..ed5e88d2b664 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -56,6 +56,7 @@ struct fence_cb;
*
* FENCE_FLAG_SIGNALED_BIT - fence is already signaled
* FENCE_FL
reducing the call size for DRM_DEBUG is a definite improvement.
Reviewed-by: Chris Wilson
>
> Miscellanea:
>
> o Convert args... to ##__VA_ARGS__
> o The equivalent DRM_DEV_ macros are rarely used and not
> worth conversion
Today. I would rather see us to migrate to DRM_DE
rhashtable
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94631
Signed-off-by: Chris Wilson
Cc: Sean Paul
Cc: David Herrmann
---
drivers/gpu/drm/drm_prime.c | 85 +++--
include/drm/drmP.h | 5 +--
2 files changed, 77 insertions(+), 13
Commit 43968d7b806d ("drm: Extract drm_plane.[hc]") was not the simple
cut'n'paste we presumed, somehow it introduced a leak of the page flip
target's framebuffer.
Fixes: 43968d7b806d ("drm: Extract drm_plane.[hc]")
Signed-off-by: Chris Wilson
Cc: Daniel Vett
driver passes the struct module to the helper.
Testcase: igt/vgem_reload_basic
Reported-by: Petri Latvala
Signed-off-by: Chris Wilson
Cc: Petri Latvala
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 3 ++-
drivers/gpu/drm/arc/arcpgu_drv.c| 4
driver passes the struct module to the helper.
v2: Use C99 initializers to zero out unset elements of
dma_buf_export_info
Testcase: igt/vgem_reload_basic
Reported-by: Petri Latvala
Signed-off-by: Chris Wilson
Cc: Petri Latvala
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu
: Daniel Vetter
Signed-off-by: Chris Wilson
Cc: Petri Latvala
Cc: Daniel Vetter
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/armada/armada_gem.c| 9 +++--
drivers/gpu/drm/drm_prime.c| 10 +-
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 +
drivers/gpu/drm/tegra/gem.c
c_source(struct drm_crtc *crtc, const char *source_name,
> size_t *values_cnt);
> +#else
> +static inline int intel_crtc_set_crc_source(struct drm_crtc *crtc,
> + const char *source_name,
> +
0253d97a ("drm/i915: Use new CRC debugfs API")
Reveiwed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
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
/vgem_basic/unload
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| 9 +++--
drivers/gpu/drm/drm_prime.c| 10 +-
drivers/gpu/drm
c() states that ctx shall be
> NULL and that an appropriate context will be chosen automatically. This
> is not what is currently implemented.
Comment is wrong.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
off-by: Chris Wilson
---
drivers/dma-buf/dma-fence.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 3444f293ad4a..9130f790ebf3 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -534,6 +53
-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 204c4a673bf3..bc99c0e292d8 100644
--- a/drivers/gpu/drm
On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
>
> On 03/01/2017 11:05, Chris Wilson wrote:
> >The struct dma_fence carries a status field exposed to userspace by
> >sync_file. This is inspected after the fence is signaled and can convey
> >whether or n
On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
>
> On 03/01/2017 11:46, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 11:05, Chris Wilson wrote:
> >>>The struct dma_fence c
On Tue, Jan 03, 2017 at 12:34:16PM +, Tvrtko Ursulin wrote:
>
> On 03/01/2017 12:13, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 11:46, Chris Wilson wrote:
> >>>On Tue, Jan 03, 2017
On Tue, Jan 03, 2017 at 01:17:19PM +, Tvrtko Ursulin wrote:
>
> On 03/01/2017 12:38, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 12:34:16PM +, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 12:13, Chris Wilson wrote:
> >>>On Tue, Jan 03, 2017
On Wed, Jan 04, 2017 at 10:15:01AM +0100, Daniel Vetter wrote:
> On Tue, Jan 03, 2017 at 02:04:44PM +, Tvrtko Ursulin wrote:
> >
> > On 03/01/2017 11:05, Chris Wilson wrote:
> > > As the fence->status is an optional field that may be set before
> > > dm
tml docs
> ;-)
How close are we to having the spine of the kernelbook described in
Documentation/ and the indiviual chapter.rst next to the source in
drivers/gpu/drm/ etc? Something like:
Documentation/gpu/drm.rst: include drivers/gpu/drm/*.rst ?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, Jan 04, 2017 at 10:37:32AM +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2017 at 09:24:27AM +0000, Chris Wilson wrote:
> > On Wed, Jan 04, 2017 at 10:15:01AM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 03, 2017 at 02:04:44PM +, Tvrtko Ursulin wrote:
> > >
On Wed, Jan 04, 2017 at 11:18:58AM +0100, Daniel Vetter wrote:
> On Wed, Jan 04, 2017 at 09:43:51AM +0000, Chris Wilson wrote:
> > On Wed, Jan 04, 2017 at 10:37:32AM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 04, 2017 at 09:24:27AM +, Chris Wilson wrote:
> > > &
a bit more.
>
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Cc: # v4.10-rc1+
> Cc: Chris Wilson
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index
off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 3444f293ad4a..9130f790ebf3 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fenc
et_status().
Signed-off-by: Chris Wilson
---
drivers/dma-buf/dma-fence.c | 25 +
drivers/dma-buf/sync_debug.c | 17 -
drivers/dma-buf/sync_file.c | 6 ++
include/linux/dma-fence.h| 24
4 files changed, 59 insertions(+), 13
adjust the
error field.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/dma-fence.c | 2 +-
include/linux/dma-fence.h | 30 +-
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index
On Wed, Jan 04, 2017 at 09:23:34PM +0530, Sumit Semwal wrote:
> Hi Chris,
>
> Thanks for your patches!
>
> On 4 January 2017 at 20:40, Daniel Vetter wrote:
> > On Wed, Jan 04, 2017 at 02:12:20PM +, Chris Wilson wrote:
> >> As the fence->status is an opti
eaningful? More
meaningful than chicken |= BIT(15); ?
> + I915_WRITE(CHICKEN_TRANS(TRANS_EDP), chicken_trans);
> } else {
> /* set up vsc header for psr1 */
> hsw_psr_setup_vsc(intel_dp);
> --
> 1.9.
On Mon, Jan 09, 2017 at 08:13:11PM +0530, Sumit Semwal wrote:
> Hi Chris,
>
> On 4 January 2017 at 19:42, Chris Wilson wrote:
> > The dma_fence.error field (formerly known as dma_fence.status) is an
> > optional field that may be set by drivers before calling
> > dm
to
demonstrate the bugs, the actual fix is still queued.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Jan 10, 2017 at 02:51:17PM +0100, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 12:45:04PM +0000, Chris Wilson wrote:
> > On Tue, Jan 10, 2017 at 01:41:54PM +0100, Geert Uytterhoeven wrote:
> > > Hi Chris, Laurent,
> > >
> > > On R-Car Gen2 (Koelsch
On Tue, Jan 10, 2017 at 05:17:46PM +0300, Dan Carpenter wrote:
> Hello Chris Wilson,
>
> The patch 560b32842912: "drm: kselftest for drm_mm and eviction" from
> Dec 22, 2016, leads to the following static checker warning:
>
> drivers/gpu/drm/selftests/test-dr
iterate over the full list, but we only
want to report the error once and once we have an error we can return
early.
Reported-by: Dan Carpenter
Fixes: 560b32842912 ("drm: kselftest for drm_mm and eviction")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Daniel Vetter
---
drive
+ if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)
goto out;
if (!mutex_trylock(&dev->mode_config.mutex)) {
The connector list is locked, but the other reads are all racy
(connector->polled, delayed_event). Those races seem intrinsic and handled
by e.g. intel_hotplug.c.
Since the locking here was only covering the connector list and that now
has its own lock,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Jan 10, 2017 at 05:34:08PM +0100, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 03:17:44PM +0000, Chris Wilson wrote:
> > On Tue, Jan 10, 2017 at 03:29:10PM +0100, Daniel Vetter wrote:
> > > -void drm_kms_helper_poll_enable_locked(struct drm_device
On Fri, Jan 13, 2017 at 04:07:00PM -0800, Dongwon Kim wrote:
> bo->global_name should be updated first before a hash value
> for the entry is calculated with it by HASH_ADD macro.
>
> Signed-off-by: Dongwon Kim
Thanks for the fix! Pushed,
-Chris
--
Chris Wilson, Intel Open So
901 - 1000 of 3784 matches
Mail list logo
