The timeline is u32, which limits any single advance to INT_MAX so that
we can detect all fences that need signaling.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers
Since sync_pt is only allocated from a single location and is no longer
the base class for fences (that is struct dma_fence) it no longer needs
a generic unsized allocator.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c | 12
Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 49 ++--
drivers/dma-buf/sync_debug.h
Often we have the task of comparing two seqno known to be on the same
context, so provide a common __dma_fence_is_later().
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
include/linux/dma-fence.h | 15 ++-
1 file changed, 14 insertions(+), 1
Quoting ville.syrj...@linux.intel.com (2017-06-29 14:49:48)
> @@ -2640,15 +2600,13 @@ static void i915_reset_device(struct drm_i915_private
> *dev_priv)
> char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
> char *reset_event[] = { I915_RESET_UEVENT "=1", NULL };
> cha
Quoting Sean Paul (2017-06-29 18:22:10)
> On Thu, Jun 29, 2017 at 01:59:29PM +0100, Chris Wilson wrote:
> > The sync_pt were not adding themselves atomically to the timeline lists,
> > corruption imminent. Only a single list is required to track the
> > unsignaled sync_pt, so
Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42)
> From: Ville Syrjälä
>
> Introduce an rw_semaphore to protect the display commits. All normal
> commits use down_read() and hence can proceed in parallel, but GPU reset
> will use down_write() making sure no other commits are in progres
Quoting Sean Paul (2017-06-29 19:10:11)
> On Thu, Jun 29, 2017 at 01:59:30PM +0100, Chris Wilson wrote:
> > Reduce the list iteration when incrementing the timeline by storing the
> > fences in increasing order.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Sumit
: Prevent spinlock recursion on free during create (next patch) and
fixup crossref in kerneldoc
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 48 ++--
drivers/dma-buf/sync_debug.c | 9
Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.
v2: Prevent spinlock recursion on free during create
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 49
Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.
v2: Prevent spinlock recursion on free during create
v3: Fixup rebase conflict inside comments that escaped the compiler.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo
n 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote:
> > > > > Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42)
> > > > > > From: Ville Syrjälä
> > > > > >
> > > > > > Introduce an rw_semaphore to protect the display
Quoting Daniel Vetter (2017-07-03 09:03:36)
> On Fri, Jun 30, 2017 at 5:39 PM, Chris Wilson
> wrote:
> >> Yeah, but my point is that this here is an extremely fancy and fragile
> >> (and afaics in this form, incomplete) fix for something that in the past
> >> was
The last user of these (i915.ko) no longer does. We can slim down the
core GEM object by removing the unused 8 bytes.
Signed-off-by: Chris Wilson
---
include/drm/drm_gem.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index
current execbuf.
>
> Cc: Chris Wilson
> ---
>
> Ideally, I'd like to get whatever kernel reviewing and/or merging is
> required to land the userspace bits ASAP. That said, I understand that
> this is my first kernel patch and it's liable to have a few rounds of
> r
Quoting Jason Ekstrand (2017-07-05 19:32:21)
> On Wed, Jul 5, 2017 at 10:37 AM, Chris Wilson
> wrote:
>
> Quoting Jason Ekstrand (2017-07-05 18:21:22)
> > This commit adds support for waiting on or signaling DRM syncobjs as
> > part of execbuf. It does so by
the drm_file parameter is unused, so remove it.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 ++
drivers/gpu/drm/drm_syncobj.c | 8 +++-
include/drm/drm_syncobj.h | 3 +--
3 files changed, 6 insertions(+), 11 deletions
Quoting Rob Clark (2017-07-11 14:38:22)
> +static unsigned long hijack_firmware_fb(struct drm_device *dev)
> +{
> + struct msm_drm_private *priv = dev->dev_private;
> + unsigned long size;
> + int i;
> +
> + /* if we have simplefb/efifb, find it's aperture and hijack
> +
Quoting Chris Wilson (2017-02-14 12:40:01)
> [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized
> memory (8802538683d0)
> [ 236.828642]
> 42001e7f0008
> [ 236.839543] i i i i u u u u i i i i i i i i
Quoting Jiri Slaby (2017-07-13 14:57:31)
> Stealing this thread as an opensuse user hit that too:
> https://bugzilla.suse.com/show_bug.cgi?id=1045105
It's a false positive. I did once upon a time send some patches to move
the lockdep warning to kref so that didn't need to call it from drm
before a
, but it looks like it
> contains quite a lot of data. If it contains actual framebuffer
> content, it may not be wise to post to mailing list
It contains command and register states. No pixel data unless userspace
got particularly creative with its memory corruption.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
request->i915;
- i915_gem_request_submit(request);
-
GEM_BUG_ON(!IS_ALIGNED(request->tail, 8));
I915_WRITE_TAIL(request->engine, request->tail);
+
+ i915_gem_request_submit(request);
}
static void i9xx_emit_breadcrumb(struct drm_i915_gem_request *
On Mon, Mar 06, 2017 at 11:15:28AM +, Chris Wilson wrote:
> On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > mplayer stopped working after a while. Dmesg says:
> > > >
> > > > [ 3000.266533] cdc_ether 2-1.2
On Mon, Mar 06, 2017 at 01:10:48PM +0100, Pavel Machek wrote:
> On Mon 2017-03-06 11:15:28, Chris Wilson wrote:
> > On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > mplayer stopped working after a while. Dmes
s first
(e.g. drm_gem_open) before the backend, so during close we should do the
driver before the core.
Maybe completely wrong ofc.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
tract drm_pci.h")
Signed-off-by: Chris Wilson
Cc: Gustavo Padovan
Cc: Daniel Vetter
---
include/drm/drm_pci.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_pci.h b/include/drm/drm_pci.h
index 5081b3eba309..9cd2173fc892 100644
--- a/include/drm/drm_p
On Fri, Mar 10, 2017 at 12:41:30AM +, Emil Velikov wrote:
> On 9 March 2017 at 22:46, Chris Wilson wrote:
> > ./include/drm/drm_pci.h:76:64: warning: ‘struct platform_device’ declared
> > inside parameter list will not be visible outside of this definition or
> > declar
> also exports the alloc and fdget functionality for the semaphore
> wrapper code.
Did you think about encapsulating a reservation object?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.
fence:
>
> while (sync_file->fence && !(fence = fence_get_rcu(sync_file->fence));
We even have a helper for that:
fence = dma_fence_get_rcu_safe(&sync_file->fence);
(Still going to suggest using a reservation_object rather than an
exclusive-only implementation.)
but
there is another possiblity for a mmap_sem recursion in the ggtt fault
handler.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
future kms driver which might have
unreliable high precision timestamping, e.g., high precision
timestamping that intermittently doesn't work.
v3: Patch before coffee needs extra coffee.
Testcase: igt/kms_vblank
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
C
Avoid adding to the waitqueue and reprobing the current vblank if the
caller is only querying the current vblank sequence and timestamp, where
we know that the wait would return immediately.
v2: Add CRTC identifier to debug messages
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel
reading our bookkeeping outside of the
vblank interrupt and outside of the explicit vblank locks.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
Cc: Laurent Pinchart
Cc: Dave Airlie ,
Cc: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 26
;
> Hmm. I'm wondering if this could give us something stale if we're just
> about to enable the vblank interrupt.
>
> We seem to set enabled=true before we update the count/ts. So I'm
> thinking we'd need to flip those around
reading our bookkeeping outside of the
vblank interrupt and outside of the explicit vblank locks.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
Cc: Laurent Pinchart
Cc: Dave Airlie ,
Cc: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 26
Order the update to vblank->enabled after the timestamp is primed so
that a concurrent unlocked reader will only see the vblank->enabled with
the current timestamp.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_irq.
On Fri, Mar 17, 2017 at 11:47:51AM +0200, Ville Syrjälä wrote:
> On Thu, Mar 16, 2017 at 11:47:48PM +0000, Chris Wilson wrote:
> > @@ -360,7 +358,7 @@ static void vblank_disable_fn(unsigned long arg)
> > unsigned long irqflags;
> >
> > spin_lock_irqsa
On Fri, Mar 17, 2017 at 11:49:32AM +0200, Ville Syrjälä wrote:
> On Thu, Mar 16, 2017 at 11:47:49PM +0000, Chris Wilson wrote:
> > Bypass all the spinlocks and return the last timestamp and counter from
> > the last vblank if the driver delcares that it is accurate (and stable
&g
add a READ_ONCE(vblank->enabled) inside the interrupt handler to
avoid missing an interrupt whilst racing with enable_vblank()
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 23 ++-
1 file changed, 14 insertions(+), 9 deleti
reading our bookkeeping outside of the
vblank interrupt and outside of the explicit vblank locks.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
Cc: Laurent Pinchart
Cc: Dave Airlie ,
Cc: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 26
akeup the waiters.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_irq.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c47e07c89136..a164cf51d093 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/
Move the repeated (a - b) <= (1 << 23) to its own function.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/
> + if (!test_and_set_bit(POLL_ENABLED, &fence->flags)) {
> + if (dma_fence_add_callback(fence, &sync_file->cb,
> +fence_check_cb_func) < 0)
> + wake
fput(sync_file->file);
So poll will wait until the fence is set before the sync_file is
signaled, but here we return NULL. At the moment this is interpretted by
the callers as an error (since we can't distinguish between the lookup
error and the empty sync_file). However, if it is empty we
ets would not be an issue, except where the
modeset is being uses to e.g. changes strides before in the middle of a
pageflip sequence.
I would welcome kms_flip flip/set/vblank-vs-probe, and definitely should
add it to legacy-cursor and legacy-plane as well.
-Chris
--
Chris Wilson, Intel Open Source Te
arning more
consistently, but I agree the helper is good documentation.
> Fixes: 935a2f776aa5 ("drm/i915: Add some selftests for sg_table manipulation")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
e_data;
What I don't like about this approach is that we leak the unwanted
inode/file. We only want the drm_file here and any access to above that
inside i915.ko is fubar.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Mar 21, 2017 at 09:56:52AM +, Chris Wilson wrote:
> On Mon, Mar 20, 2017 at 10:40:28AM +0100, Arnd Bergmann wrote:
> > We get a warning with gcc-7 about a pointless comparison when
> > using a linear memmap:
> >
> > drivers/gpu/drm/i915/selftests
Move the repeated (a - b) <= (1 << 23) to its own function.
v2: Catch the '1<<23' inside drm_handle_vblank() as well
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
---
drivers/gpu/drm/drm_irq.c | 16 ++--
1 file cha
the entire flip sequence whereas before it would
flip-flop around every interrupt.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
Cc: Laurent Pinchart
Cc: Dave Airlie ,
Cc: Mario Kleiner
---
drivers/gpu/drm/drm_irq.c | 18 +++---
1 file changed,
Better subject might be
drm: Use vblank irq shadow for entire flip sequence
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
r message being
> printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
> use a null vpgu as the macro has a sanity check to see if vpgu is null,
> so this is OK.
It is never NULL, it gets checked by its only caller.
-Chris
--
Chris Wilson, Intel Open
rom the
vblank_event_lock.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
the entire flip sequence whereas before it would
flip-flop around every interrupt.
v2: Move the disable_fn() call outside of the vblank_event_lock.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Michel Dänzer
Cc: Laurent Pinchart
Cc: Dave Airlie ,
Cc: Mario Kleiner
Revie
Scatter a few cond_resched() in between phases of the drm_mm selftests
to try and prevent us incurring the wrath of the NMI watchdog.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/selftests/test-drm_mm.c | 28
1 file changed, 28 insertions
uot;.
debugfs / seq_file is not performance critical. Familiar idiomatic code is
much preferred over continually switching between seq_printf and seq_puts.
And don't even start on converting seq_printf / seq_puts to seq_putc...
-Chris
--
Chris Wilson, Intel
ion inaccurate because somebody holds a
> forcewake reference.\n");
And now you break the 80col rule. Blind adherence to checkpatch is
impossible.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
struct device *attach_dev)
My critique would be that this should be called
drm_gem_prime_import_for_device()
Either way (though naturally I like my suggestion ;),
Reviewed-by: Chris Wilson
-Chris
>
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> Reviewed-by: Chris Wilson
> Signed-off-by: Laura Abbott
> ---
> v4: Switch from the now removed platformdev to a static platform device.
I was thinking of avoiding the static, i.e.
static struct vgem_device {
struct drm_device drm;
struct device *platform;
On Thu, May 04, 2017 at 11:45:48AM -0700, Laura Abbott wrote:
>
> Enable the GEM dma-buf import interfaces in addition to the export
> interfaces. This lets vgem be used as a test source for other allocators
> (e.g. Ion).
>
> Reviewed-by: Chris Wilson
> Signed-off-by: Lau
grepping for a complete seq_printf() is unlikely (i.e. you had
to open the debugfs file to see it, so you must already know where to
look in the code).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, May 04, 2017 at 09:09:54PM -0700, Joe Perches wrote:
> On Thu, 2017-05-04 at 21:25 +0100, Chris Wilson wrote:
> > On Thu, May 04, 2017 at 11:45:48AM -0700, Laura Abbott wrote:
> > >
> > > Enable the GEM dma-buf import interfaces in addition to the export
>
ilable to it, is unable to reapply the existing
rotation - i.e. why this is a kernel problem, and whether by hiding this
from userspace we are not trapping ourselves with warts in the ABI.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
With Laura's introduction of the fake platform device for importing
dmabuf, we add a second static that is logically tied to the vgem_device.
Convert vgem over to using the struct drm_device subclassing, so that
the platform device is stored inside its owner.
Signed-off-by: Chris Wilso
On Tue, May 09, 2017 at 12:26:34PM +1000, Dave Airlie wrote:
> On 4 May 2017 at 18:16, Chris Wilson wrote:
> > On Wed, Apr 26, 2017 at 01:28:29PM +1000, Dave Airlie wrote:
> >> +#include
> >
> > I wonder if Daniel has already split everything used here into its own
'struct device' declared inside
> parameter list will not be visible outside of this definition or
> declaration
> struct device *attach_dev);
We aren't using it for anything other than an opaque pointer, so a
struct device;
forward decl will suffic
ma_fence_wait_timeout(fence, true, timeout);
Doesn't handle -EINTR yet with timeout. If having a drmIoctl() that
can't be tricked into turning a short waiting into an indefinite one is a
goal.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
until it is first used.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
---
drivers/dma-buf/sync_file.c | 18 +++---
include/linux/sync_file.h | 2 +-
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf
until it is first used.
v2: Update kerneldoc (kbuild test robot)
v3: sync_debug.c was peeking at the name
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
---
drivers/dma-buf/sync_debug.c | 3 ++-
drivers/dma-buf/sync_file.c | 34 +++---
include
As we can have multiple tx in the queue, with individual waiters, make
sure that all are woken when any state changes (so that we are sure the
right owner of the txmsg is woken).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
1 file changed, 3 insertions(+), 3
Both as an exercise to document that we are reading the state outside of
the appropriate mutex and to ensure that we only read the value once
before the multiple comparisons, use READ_ONCE.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8
1 file changed, 4
subject s/Wait/Wake/
D'oh
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, May 15, 2017 at 09:01:29AM +0200, Daniel Vetter wrote:
> On Fri, May 12, 2017 at 07:55:42PM +0100, Chris Wilson wrote:
> > Constructing the name takes the majority of the time for allocating a
> > sync_file to wrap a fence, and the name is very rarely used (only via
&g
spinlock
to serialize the assignment of the name.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Daniel Vetter
---
drivers/dma-buf/sync_debug.c | 3 ++-
drivers/dma-buf/sync_file.c | 54 ++--
include/linux/sync_file.h| 5 ++--
3
On Mon, May 15, 2017 at 12:50:04PM +0200, David Herrmann wrote:
> Hey
>
> On Mon, May 15, 2017 at 12:10 PM, Chris Wilson
> wrote:
> > Constructing the name takes the majority of the time for allocating a
> > sync_file to wrap a fence, and the name is very rarely used (on
MM has a better idea
> how to implement fallbacks (e.g. do not vmalloc before kmalloc is tried
> with __GFP_NORETRY).
Better? The same idea. The only difference I was reluctant to hand out
large pages for long lived objects. If that's the wisdom of the core mm,
so be it.
Reviewed-by: Chris W
On Tue, May 16, 2017 at 12:53:52PM +0200, Michal Hocko wrote:
> On Tue 16-05-17 10:31:19, Chris Wilson wrote:
> > On Tue, May 16, 2017 at 11:06:06AM +0200, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > drm_malloc* has grown their own kmalloc with vm
spinlock
to serialize the assignment of the name.
v5: Completely avoid the read/write race by only storing the name passed
in from the user inside sync_file->user_name and passing in a buffer to
dynamically construct the name otherwise.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Pado
little surprised that calloc_large users still exist.
Reviewed-by: Chris Wilson
One more feature request from mm, can we have the
if (size != 0 && n > SIZE_MAX / size)
check exported by itself. It is used by both kvmalloc_array and
kmalloc_array, and in my ioctls I have it ope
On Wed, May 17, 2017 at 09:44:53AM +0200, Michal Hocko wrote:
> On Tue 16-05-17 12:09:08, Chris Wilson wrote:
> > On Tue, May 16, 2017 at 12:53:52PM +0200, Michal Hocko wrote:
> > > On Tue 16-05-17 10:31:19, Chris Wilson wrote:
> > > > On Tue, May 16, 2017 at 11:06:
On Wed, May 17, 2017 at 11:03:50AM +0200, Michal Hocko wrote:
> On Wed 17-05-17 08:38:09, Chris Wilson wrote:
> > On Wed, May 17, 2017 at 08:55:08AM +0200, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > drm_[cm]alloc* has grown thei
ot, we tried walling
it off to prevent it being accidentally enabled... Otherwise, it looks
like we need a bit of printk debugging to work out just what it doesn't
like.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Dead Code")
>
> Fixes: 47624cc3301b60 ("drm/i915: Import the kfence selftests for
> i915_sw_fence")
> Signed-off-by: Colin Ian King
Thanks, obviously correct and not exercised by BAT so pushed.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
drm/i915: Check C for null pointer rather than B
Thanks for the patch.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
I was fixing an
> earlier issue.)
>
> Detected by CoverityScan, CID#1436406 ("Dereference null return")
>
> Fixes: 47624cc3301b60 ("drm/i915: Import the kfence selftests for
> i915_sw_fence")
> Signed-off-by: Colin Ian King
Pushed, thanks very much fo
PTR return on failure, so
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
as a secondary display.
What's primary and secondary? Do you mean X's RandR PrimaryOutput, or
the layout, both of which are provided by userspace. I suspect what you
mean is that the connectors were relabelled, so the output from
before/after xrandr might help to clarify that.
-Chris
--
On Tue, May 16, 2017 at 12:10:42PM +0100, Chris Wilson wrote:
> Constructing the name takes the majority of the time for allocating a
> sync_file to wrap a fence, and the name is very rarely used (only via
> the sync_file status user interface). To reduce the impact on the common
> p
is doesn't make sense.
See the Kconfig "choice" directive.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
I laud the motive, afaict drm_vblank_cleanup() is still required
after drm_vblank_init(), if only to kfree(dev->vblank). I didn't see
that change in the earlier patches...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
the cursors do remain async.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
uct
> drm_syncobj_create)
> +#define DRM_IOCTL_SYNCOBJ_DESTROYDRM_IOWR(0xC0, struct
> drm_syncobj_destroy)
These two only need DRM_IOW.
> +#define DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD DRM_IOWR(0xC1, struct
> drm_syncobj_handle)
> +#define DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE
t_handles, sizeof(uint32_t),
> + GFP_KERNEL);
> + if (handles == NULL)
> + return -ENOMEM;
> +
> + if (copy_from_user(handles,
> +(void __user *)(unsigned long)(args->handles),
> +sizeof(uint32_t) * args->count_handles)) {
> + ret = -EFAULT;
> + goto err_free_handles;
> + }
> +
> + if (args->flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL)
> + ret = drm_syncobj_wait_all_fences(dev, file_private,
> + args, handles);
> + else
> + ret = drm_syncobj_wait_any_fence(dev, file_private,
> + args, handles);
> +err_free_handles:
> + kfree(handles);
> +
> + return ret;
> +}
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
|| args->flags)
> + if (args->pad)
> + return -EINVAL;
> +
> + if (args->flags != 0 &&
> + args->flags !=
> DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_FENCE_SYNC_FILE)
> return -EINVAL;
DRM_SYNCOBJ_HANDLE_T
gt; drm_dev_unregister again. Since drm_dev_unregister is not protected
> against being called multiple times this leads to havoc.
>
> This commit fixes this by calling drm_dev_unref instead of drm_put_dev.
>
> Fixes: a39be606f99d ("drm: Do a full device unregister when unpluggi
imes this leads to havoc.
> > >
> > > This commit fixes this by calling drm_dev_unref instead of drm_put_dev.
> > >
> > > Fixes: a39be606f99d ("drm: Do a full device unregister when unplugging")
> > > Cc: Chris Wilson
> One more: When
-488,12 +488,6 @@ static __inline__ int drm_core_check_feature(struct
> > drm_device *dev,
> > return ((dev->driver->driver_features & feature) ? 1 : 0);
> > }
> >
> > -static inline void drm_device_set_unplugged(struct drm_device *dev)
> > -{
>
)
{
unsigned ret;
+ if (len <= 16)
+ return copy_user_generic_unrolled(to, from, len);
is enough to speed up i915_gem_busy_ioctl() by 10% :|
Note that this overhead may entirely be x86 specific.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/
On Tue, May 30, 2017 at 01:55:20PM +0100, Chris Wilson wrote:
> When looking at simple ioctls coupled with conveniently small user
> parameters, the overhead of the syscall and drm_ioctl() present large
> low hanging fruit. Profiling trivial microbenchmarks around
> i915_gem_busy_io
> Reviewed-by: Sean Paul
> Signed-off-by: Dave Airlie
Thanks for find/replace, saves me having to export them later :)
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel
801 - 900 of 3785 matches
Mail list logo
