Jingfeng,
Does your design have any bus PMU counters that can be used to measure
DRAM bandwidth of the 3D GPU directly or even indirectly?
Regards,
Chris
On Thu, Jun 15, 2023 at 2:53 AM Lucas Stach wrote:
>
> Am Donnerstag, dem 15.06.2023 um 17:37 +0800 schrieb Sui Jingfeng:
On Tue, May 23, 2023 at 12:27:56PM -0700, Douglas Anderson wrote:
> In a whole pile of panel drivers, we have code to make the
> prepare/unprepare/enable/disable callbacks behave as no-ops if they've
> already been called. It's silly to have this code duplicated
> everywhere. Add it to the core ins
In my case a few different panel drivers disable the regulators in the
unprepare/disable routines. For at least the Rockchip DSI
implementations for some reason the panel gets unprepared more than
once, which triggers an unbalanced regulator disable. Obviously though
the correct course of action is
On Mon, Jul 31, 2023 at 07:03:07PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Mon, Jul 31, 2023 at 11:33:22AM -0500, Chris Morgan wrote:
> > In my case a few different panel drivers disable the regulators in the
> > unprepare/disable routines.
>
> And that's total
From: Chris Morgan
Add support for the Anbernic RG351V panel. This panel is mostly
identical to the one used in the 353 series, except it has a different
panel ID when queried (0x4000 for the 351V, 0x3052 for the 353 panel)
and will not work without the inclusion of the
From: Chris Morgan
Add support for the Anbernic 351V. Just like the 353 series the
underlying vendor is unknown/unmarked (at least not visible in a
non-destructive manner). The panel had slightly different init
sequences and timings in the BSP kernel, but works fine with the
same ones used in
From: Chris Morgan
Document the Anbernic RG351V panel, which appears to be identical to
the panel used in their 353 series except for in inclusion of an
additional DSI format flag.
Signed-off-by: Chris Morgan
---
.../display/panel/newvision,nv3051d.yaml | 18 +++---
1 file
From: Chris Morgan
Document the Anbernic RG351V panel, which appears to be identical to
the panel used in their 353 series except for in inclusion of an
additional DSI format flag.
Signed-off-by: Chris Morgan
---
.../display/panel/newvision,nv3051d.yaml | 18 ++
1 file
From: Chris Morgan
Add support for the Anbernic RG351V panel. This panel is mostly
identical to the one used in the 353 series, except it has a different
panel ID when queried (0x4000 for the 351V, 0x3052 for the 353 panel)
and will not work without the inclusion of the
From: Chris Morgan
Add support for the Anbernic 351V. Just like the 353 series the
underlying vendor is unknown/unmarked (at least not visible in a
non-destructive manner). The panel had slightly different init
sequences and timings in the BSP kernel, but works fine with the
same ones used in
On Thu, Aug 10, 2023 at 05:24:09PM -0600, Rob Herring wrote:
> On Wed, Aug 09, 2023 at 10:39:40AM -0500, Chris Morgan wrote:
> > From: Chris Morgan
> >
> > Document the Anbernic RG351V panel, which appears to be identical to
> > the panel used in their 353 series ex
On Fri, Aug 11, 2023 at 09:41:50AM -0500, Chris Morgan wrote:
> On Thu, Aug 10, 2023 at 05:24:09PM -0600, Rob Herring wrote:
> > On Wed, Aug 09, 2023 at 10:39:40AM -0500, Chris Morgan wrote:
> > > From: Chris Morgan
> > >
> > > Document the Anbernic RG351V pan
t; + }
> +
> + list_add_tail(&waiter->list, &cur->list);
> + return 0;
> + }
> + }
> +
> + list_add_tail(&waiter->list, &lock->wait_list);
> + return 0;
> +}
--
Chris Wilson, Intel Open Source Technology Centre
+ verbose_prune);
>
> This call to drm_mode_prune_invalid is probably just to paper over a bug
> in SNA - SNA violates the hotplug handling uabi by not unconditionally
> reprobing. Inconsistently paper over that bug in the kernel is not good,
> userspace interfaces need to be well defined. Please remove this call and
> test with either UXA or -modesetting until SNA is fixed.
This is not required for link retraining in userspace, since userspace's
response to seeing the link-status == BAD property is to retrain the
current mode (and then it checks link-status again to see if the modeset
worked because returning an error from the modeset seems troublesome).
After that it reprobes. However, the kernel must still fail the modeset
following link-status = BAD if it decides that the mode is no longer
valid.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ot good,
> userspace interfaces need to be well defined. Please remove this call and
> test with either UXA or -modesetting until SNA is fixed.
Then you should also categorically state that (once again) misusing the
HOTPLUG uevent for notification of a property update is wrong.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
igt/drm_mm
Fixes: 202b52b7fbf7 ("drm: Track drm_mm nodes with an interval tree")
Signed-off-by: Chris Wilson
Cc: David Herrmann
Cc: dri-devel at lists.freedesktop.org
Cc: Daniel Vetter
Cc: # v4.9-rc1+
---
drivers/gpu/drm/drm_mm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/
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
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| 2 +-
drivers/gpu/drm/drm_prime.c| 30 +-
drivers/gpu/drm/i915
On Wed, Oct 05, 2016 at 03:11:00PM +0200, Daniel Vetter wrote:
> On Fri, Sep 30, 2016 at 02:59:59PM +0100, Chris Wilson wrote:
> > In order to keep the dmabuf alive whilst the mmap is, we need to hold a
> > reference to the dmabuf and not the backing object. This is important as
>
I hit send before completing a make htmldoc, and lo I forgot to fix up
the cut'n'paste.
Fixes: a4fce9cb782a ("drm/prime: Take a ref on the drm_dev when exporting...")
Reported-by: kbuild test robot
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: stable at vger.kernel.org
all these hardcoded values
> to PLANE_X, and convert "int"s  to "enum plane"s everywhere.
Note that this is not PLANE_A, but setting up a shorthand local for
const struct skl_plane_wm *p_wm = crtc_state->wm.skl.optimal.planes;
-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 Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
Plus equivalents in drm_plane.h, drm_encoder.h ...
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
fe5a66f91c88 ("drm/i915: Read PSR caps/intermediate freqs/etc. only
> once on eDP")
> Signed-off-by: Dan Carpenter
Oops, does smatch catch this? I don't recall seeing the complaint in
recent runs?
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
m_minor to drm_device
>
> Noticed by Chris Wilson.
>
> Fixes: 95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device")
> Cc: Chris Wilson
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Cc: Emil Velikov
> Cc: Julia Lawall
> Signed-off-by: Daniel Vetter
() itself with the bad block printing from
get_edid_block(), into a single warning associated with the connector
once all attempts to retrieve the EDID fail.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_edid.c | 82
active_list) {
> - if (fence_is_signaled_locked(&pt->base))
> + struct fence *fence = fence_get(&pt->base);
> + bool signaled;
> +
> + spin_unlock_irqrestore(&obj->child_list_lock, flags);
Hmm. The obj->chi
On Fri, Oct 14, 2016 at 01:46:37PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 13, 2016 at 08:43:55PM +0100, Chris Wilson wrote:
> > Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
> > intermediate edid reads. This causes transient failures in CI which
&
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
e been
by the caller). That spares us the issue of the flags being changed
here, and the changed flags not being propagated back.
We need only grab the list under the lock once, as once signaled no new
elements will be added to the list (after add_callback takes the lock it
checks for the signal).
i.e.
struct list_head cb_list;
list_splice_init(&fence->cb_list, &cb_list;
spin_unlock(fence->lock);
list_for_each_entry_safe(cur, tmp, &cb_list, node)
cur->func(fence, cur);
spin_lock(fence->lock);
Though I'm not convinced that dropping the lock is going to be safe for
everyone, since that lock may be communal and guarding move than just
the cb_list, e.g. virtio_gpu_fence_event_process().
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
since the fences put onto the wq
should be independent and can work in parallel. system_unbound should
suffice.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Sun, Oct 16, 2016 at 02:29:51PM -0400, Rob Clark wrote:
> On Sun, Oct 16, 2016 at 1:49 PM, Chris Wilson
> wrote:
> > On Sun, Oct 16, 2016 at 12:39:35PM -0400, Rob Clark wrote:
> >> This is the alternative approach for solving a deadlock situation with
> >> arr
Now that we have the name "block" free once more, we can use it to point
to the start of a block within the edid.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_edid.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/d
The "block" variable points to the entire edid, not individual blocks
despite it being named such.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_edid.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/dr
() itself with the bad block printing from
get_edid_block(), into a single warning associated with the connector
once all attempts to retrieve the EDID fail.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_edid.c | 42
on that is unlikely
> to be useful in the case of fence-arrays. If you need to wait on
> multiple fences from different timelines, you probably aren't doing
> that in hw.
For 2 i915 fences, I definitely do not want signaling enabled at
creation time.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
pturing frame CRCs")
> Cc: Benjamin Gaignard
> Cc: Daniel Vetter
> Cc: Emil Velikov
> Cc: Tomeu Vizoso
> Signed-off-by: Jani Nikula
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
irst.
>
> Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
> Cc: Chris Wilson
> Cc: Daniel Vetter
> Signed-off-by: Arnd Bergmann
Yup, missed that it jumps to fail before allocating state.
Function still looks a bit odd, but nvm
Reviewed-by: Ch
1136 deletions(-)
Mostly generated with the provided cocci spatch, but even with
--include-headers it seemed to miss some headers, and I never quite
worked out the substition commands for macros, so there is some grep and
replace.
-Chris
+ dma_fence_wait
|
- fence_context_alloc
+ dma_fence_context_alloc
|
- FENCE_TRACE
+ DMA_FENCE_TRACE
|
- FENCE_WARN
+ DMA_FENCE_WARN
|
- FENCE_ERR
+ DMA_FENCE_ERR
)
(
...
)
Signed-off-by: Chris Wilson
---
drivers/base/Kconfig | 6 +-
drivers/dma-buf/Makefile
On Thu, Oct 20, 2016 at 10:39:47AM -0400, Sean Paul wrote:
> On Thu, Oct 20, 2016 at 2:47 AM, Chris Wilson
> wrote:
> > I plan to usurp the short name of struct fence for a core kernel struct,
> > and so I need to rename the specialised fence/timeline for DMA
> >
the vma (or the bo as well as the vma).
> + dev_priv->perf.oa.oa_buffer.addr = i915_gem_object_pin_map(bo, map);
> + if (IS_ERR(dev_priv->perf.oa.oa_buffer.addr)) {
> + ret = PTR_ERR(dev_priv->perf.oa.oa_buffer.addr);
> + goto err_unpin;
> + }
--
Chris Wilson, Intel Open Source Technology Centre
).
Signed-off-by: Chris Wilson
Cc: Villle Syrjälä
Cc: Manasi Navare
---
drivers/gpu/drm/drm_probe_helper.c | 10 ++
drivers/gpu/drm/drm_sysfs.c| 19 +++
drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
drivers/gpu/drm/i915/intel_dp.c| 3 ++-
drivers
Date: Thu Oct 20 14:08:48 2016 +0800
drm/i915/gvt: fix spare warnings on odd constant _Bool cast
The function return values should has type int if it return
a integer value.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
).
v2: Don't convert intel_hotplug.c, it does a light probe and doesn't
need the force.
Signed-off-by: Chris Wilson
Cc: Villle Syrjälä
Cc: Manasi Navare
---
drivers/gpu/drm/drm_probe_helper.c | 10 ++
drivers/gpu/drm/drm_sysfs.c| 19 +++
drive
xercise this and at least for OACONTROL we are
fine. That test can supercede the negative BAT in gem_exec_parse.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Oct 21, 2016 at 12:46:53PM +0300, Ville Syrjälä 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
iled
Reported-by: kbuild test robot
Reported-by: Leonard Crestez
Fixes: 43dc7fe2b211 ("drm: Mark up accesses of vblank->enabled outside of its
spinlock")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 4 +++-
1 file changed, 3 in
if (a->type != b->type)
> return NULL;
> + if (a->type != SYNC_FILE_TYPE_FENCE)
> + return NULL;
No rules for containerisation? Being able to pass in an array of current
semaphore in-fences through a single fd? It will have a bigg
On Tue, Apr 04, 2017 at 12:52:32PM +0100, Chris Wilson wrote:
> On Tue, Apr 04, 2017 at 02:27:30PM +1000, Dave Airlie wrote:
> > +struct dma_fence *sync_file_replace_fence(struct sync_file *sync_file,
> > + struct dma_fence *fence)
> &
g vgem to justify the
changes? I'm also not particularly happy in losing testing of a virtual
platform device from our CI.
-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
nd the scheduled bit is cleared before the work
is executed). So we aren't saving the kworker from having to process
another work, but we may make that having nothing to do. The question is
whether we want to trap the kworker here, and presumably you will also want
to add a cond_resched() between pas
es to the reclaim code in addition of waiting a RCU grace
> period to pass.
We are not allowed to call flush_work() from the shrinker, the workqueue
doesn't have and can't have the right reclaim flags.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Fri, Apr 07, 2017 at 01:23:45AM +0200, Andrea Arcangeli wrote:
> Just in case the llist model changes and NULL isn't valid
> initialization.
>
> Signed-off-by: Andrea Arcangeli
Applied, thanks.
-Chris
--
Chris Wilson, Intel Open Source
e6b10 R14: 0004 R15: 007e61f4
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100610
Fixes: e8fa5671183c ("drm: crc: Wait for a frame before returning from open()")
Signed-off-by: Chris Wilson
Cc: Tomeu Vizoso
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_de
On Fri, Apr 07, 2017 at 03:06:00PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 11:02:11AM +0100, Chris Wilson wrote:
> > On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> > > Waiting a RCU grace period only guarantees the work gets queued, but
>
On Fri, Apr 07, 2017 at 09:18:30AM -0700, Laura Abbott wrote:
> On 04/07/2017 12:39 AM, Chris Wilson wrote:
> > On Thu, Apr 06, 2017 at 04:18:33PM -0700, Laura Abbott wrote:
> >>
> >> Enable the GEM dma-buf import interfaces in addition to the export
> >> int
On Fri, Apr 07, 2017 at 06:42:46PM +0200, Daniel Vetter wrote:
> On Fri, Apr 07, 2017 at 01:55:00PM +0200, Tomeu Vizoso wrote:
> > On 04/07/2017 01:17 PM, Chris Wilson wrote:
> > > The code does not like to be interrupted when waiting for the first
> > > vblank after op
sation if
they so choose.
Signed-off-by: Chris Wilson
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: Sean Paul
---
drivers/dma-buf/dma-buf.c | 88 +++
1 file changed, 88 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-b
sation if
they so choose.
v2: Lots of little fixes, plus a real llseek() implements so that the
first basic little test cases work!
Testcase: igt/prime_rw
Signed-off-by: Chris Wilson
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: Sean Paul
---
drivers/dma-buf/dma-buf.c
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT.
Signed-off-by: Chris Wilson
Cc: Tvrtko
2 clflushes on two different objects are not ordered, and so do not
belong to the same timeline (context). Either we use a unique context
for each, or we reserve a special context (0 / DMA_FENCE_NO_CONTEXT) to
mean unordered.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc
Reserve 0 for general use a token meaning that the fence doesn't belong
to an ordered timeline (fence context).
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: Joonas Lahtinen
Cc: "Christian König"
Cc: Alex Deucher
---
drivers/dma-buf/dma-fence.c |
On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote:
> Am 08.04.2017 um 18:26 schrieb Chris Wilson:
> >Reserve 0 for general use a token meaning that the fence doesn't belong
> >to an ordered timeline (fence context).
>
> NAK, we kept context allocation c
On Sun, Apr 09, 2017 at 09:08:53AM +0200, Christian König wrote:
> Am 08.04.2017 um 20:00 schrieb Chris Wilson:
> >On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote:
> >>Am 08.04.2017 um 18:26 schrieb Chris Wilson:
> >>>Reserve 0 for general use a token
On Fri, Apr 07, 2017 at 06:48:58PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 04:30:11PM +0100, Chris Wilson wrote:
> > Not getting hangs is a good sign, but lockdep doesn't like it:
> >
> > [ 460.684901] WARNING: CPU: 1 PID: 172
a
memset(prop_values, 0xc5, foo);
drmIoctl(GETPROPERTY);
igt_assert(!memchr(prop_values, 0xc5, bar));
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://
wake_up(&sync_file->wq); /* only needs the first to redo the add */
}
will get the waiter to reset the callback on a new fence, or the old
fence replacing itself. Otherwise the waiter will never be woken over
the change in fence, not even when the old or new fence is signa
ease conduct yourself in a respectful and civilised manner when
> +interacting with community members on mailing lists, IRC, or bug
> +trackers. The community represents the project as a whole, and abusive
> +or bullying behaviour is not tolerated by the project.
Self-englightened Acked-by: Ch
truct dma_fence *fence)
> +{
> + struct vc4_fence *f = to_vc4_fence(fence);
> +
> + kfree_rcu(f, base.rcu);
> +}
Unless you have a plan to do more here, looks like you can just use
the default dma_fence_free as the release callback.
-Chris
--
Chris Wilson, Intel Open Sourc
ines. Searching kronos for VkSemaphore
https://www.khronos.org/registry/vulkan/specs/1.0/man/html/VkSemaphore.html
isn't enlightening...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.free
On Wed, Apr 12, 2017 at 09:37:02AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> sync_file uses the reference count of the file, the internal
> kref was never getting moved past 1.
>
> We can reintroduce this if we decide we need it later.
>
> Signed-off-by: Dave Ai
hat happens when the fence in the sync object
> was changed while we do the CS? Or even worse the handle got
> assigned to a new sync object.
We either ww_mutex the lot, or regard that as a userspace race where the
order between the two concurrent CS emits is undefined and who gets the
in-sema
On Wed, Apr 12, 2017 at 12:36:37PM +1000, Dave Airlie wrote:
> On 11 April 2017 at 17:50, Chris Wilson wrote:
> > On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> This object can be used to implement the Vul
s an interesting debug story.
No, the rcu hang was not widely reported (or at least I have just two hits),
it dates back to ~v4.9. What was annoying many people was us failing to
write out the legacy context image under mempressure/suspend, which was
sent in the previous fixes cycle.
-Chris
On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
> On 04/07/2017 02:25 PM, Chris Wilson wrote:
> > It is expected that processes will pass dma-buf fd between drivers, and
> > only using the fd themselves for mmaping and synchronisation ioctls.
> > However, it may
to handle it in the fops. Just be sure to leave a breadcrumb behind so
that the first person who does try to pass back a syncobj fd is reminded
that they need to fill in the fops.
-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 Wed, Apr 12, 2017 at 12:57:00PM -0700, Laura Abbott wrote:
> On 04/12/2017 12:38 PM, Chris Wilson wrote:
> > On Wed, Apr 12, 2017 at 11:29:18AM -0700, Laura Abbott wrote:
> >> Both the read/write are missing the dma_buf_begin_cpu_access calls.
> >> When I add th
On Wed, Apr 12, 2017 at 09:01:32PM +0100, Chris Wilson wrote:
> On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote:
> > >>
> > >> Not sure what the best semantics are there, any opinions on barring
> > >> wakeups/polling on semaphore sync_files, and
On Thu, Apr 13, 2017 at 06:51:17AM +1000, Dave Airlie wrote:
> On 13 April 2017 at 06:39, Chris Wilson wrote:
> > On Wed, Apr 12, 2017 at 09:01:32PM +0100, Chris Wilson wrote:
> >> On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote:
> >> > >>
> &
fence *fence;
};
could be extracted and sync_file become fence_file. Would it not help to
avoid any further confusion by treating them as two very distinct classes
of fd?
And for me to stop calling the user interface sync_file.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
ret_fence = sem_file_get_fence_locked(sem_file);
> + RCU_INIT_POINTER(sem_file->base.fence, fence);
> + mutex_unlock(&sem_file->lock);
Is xchg() universal?
struct dma_fence *sem_file_replace_fence(struct sem_file *sem_file,
10 13:54:45 2017 +0200
drm: Fix get_property logic fumble
Yet again I've proven that I can't negate conditions :(
Testcase: igt/kms_properties/get_property-sanity
Reviewed-by: Maarten Lankhorst
Reviewed-by: Sean Paul
Fixes: eb8eb02ed850 (&q
On Thu, Apr 13, 2017 at 10:52:17PM +0300, Dan Carpenter wrote:
> i915_gem_request_alloc() uses error pointers. It never returns NULLs.
>
> Fixes: 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
> Signed-off-by: Dan Carpenter
Reviewed-by: Chris Wilson
ev for load-detection framebuffer\n");
if (IS_ERR(fb)) {
DRM_DEBUG_KMS("failed to allocate framebuffer for
load-detection\n");
+ ret = PTR_ERR(fb);
goto fail;
}
as well.
-Chris
--
Chris Wilson, Intel Open Source Technology
>
> My plans are to write some igt tests this week, and try
> to get some more review on what the API should allow (should
> I lock it down to drm syncobj is just semaphores for now).
Having an idr of handles is much, much nicer than fd and I want the same
for fences :)
-Chris
--
On Fri, Apr 14, 2017 at 10:54:25PM +0300, Dan Carpenter wrote:
> If "crtc" is NULL, then my static checker complains that "ret" isn't
> initialized on that path. It doesn't really cause a problem unless
> "ret" is somehow set to -EDEADLK which is n
On Wed, Apr 19, 2017 at 05:34:52AM +1000, Dave Airlie wrote:
> On 14 April 2017 at 19:45, Chris Wilson wrote:
> > On Tue, Apr 11, 2017 at 01:22:12PM +1000, Dave Airlie wrote:
> >> This set of sync object patches should address most of the issues
> >> raised in review.
a_buf))
> + return dma_buf;
> +
> + drm_dev_ref(dev);
> + drm_gem_object_reference(obj);
> +
> + return dma_buf;
> }
Please see drm_gem_dmabuf_export() and drm_gem_dmabuf_release() - unless
the double drm_dev_ref() wasn't an accident...
-Chris
--
dump is attached in case it is useful.
There are lots of very similar GPU hangs for mesa across a wide range of
kernels, with several reports noting a correlation with libreoffice.
At first glance, I would say you were just unlucky to hit it.
-Chris
--
Chris Wilson, Intel Open Source
drm_free_large(vgem_obj->pages);
Just drm_free_large(vgem_obj->pages); NULL -> kfree() which is NULL safe.
The series lgtm, doesn't compromise on any of the existing tests.
All 3,
Reviewed-by: Chris Wilson
You could always get Joonas to nitpick over style...
>
ffer be resident in memory.
>
> I'm still marking this as RFC as I haven't had a chance to finish
> a userspace test that can be integrated into igt.
Note, that it will be good to cc:intel-gfx@ so that our CI does run it
over the existing vgem tests.
-Chris
function to attach using a platform device associated
> with drm_device.
>
> Cc: intel-...@lists.freedesktop.org
> Reviewed-by: Chris Wilson
> Signed-off-by: Laura Abbott
> ---
> v3: Rebase to drm-misc-next. Prototype moved to a new header file. Comments
> added for n
On Wed, May 03, 2017 at 05:07:03PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 07:40:51AM -0700, Laura Abbott wrote:
> > On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> > > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> > >> On Tue, May 02, 2
On Thu, Mar 30, 2017 at 01:16:26PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-03-29 at 10:10 +0100, Chris Wilson wrote:
> > 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.
> >
>
gal to call this
> + * without already holding a reference. No locks required.
> + */
> +static inline void
> +drm_syncobj_reference(struct drm_syncobj *obj)
> +{
> + kref_get(&obj->refcount);
We've been steadily converting to the kref_get style of nomenclature for
dr
INT and keeping
the maximum waittime intact.
> + dma_fence_put(fence);
> + if (ret < 0)
> + return ret;
> + if (ret == 0)
> + break;
> + }
> +
> + wait->out_status = (ret > 0);
> +
drm_dev_fini() and kfree(dev) as before.)
v3: Remember to add drm_dev_fini() to drm_drv.h
v4: Tidy language for kerneldoc
v5: Cross reference from drm_dev_init() to note that driver->release()
allows for arbitrary embedding.
Signed-off-by: Chris Wilson
Cc: Laurent Pinchart
Cc: Daniel Vetter
---
driv
Currently this tracepoint is solely used by dma_fence_enable_sw_signaling,
however I have a need to manually perform the hw enabling of the
signaling and would like to emit this tracepoint for completeness.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Daniel Vetter
---
drivers/dma-buf/dma
801 - 900 of 4552 matches
Mail list logo
