== Series Details ==
Series: Adding driver-private objects to atomic state
URL : https://patchwork.freedesktop.org/series/23308/
State : success
== Summary ==
Series 23308v1 Adding driver-private objects to atomic state
https://patchwork.freedesktop.org/api/1.0/series/23308/revisions/1/mbox/
From: "Pandiyan, Dhinakaran"
Use the added helpers to track MST link bandwidth for atomic modesets.
Link bw is acquired in the ->atomic_check() phase when CRTCs are being
enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots().
Similarly, link bw is released during ->atomic_che
From: "Pandiyan, Dhinakaran"
It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and cle
From: "Pandiyan, Dhinakaran"
drm_dp_atomic_find_vcpi_slots() should be called from ->atomic_check() to
check there are sufficient vcpi slots for a mode and to add that to the
state. This should be followed by a call to drm_dp_mst_allocate_vcpi()
in ->atomic_commit() to initialize a struct vcpi fo
Changes in this version:
Used connector->atomic_check() to release vcpi slots instead of the
atomic_release() callback.
This series introduces void * type driver-private objects in core and adds
helper functions that operate on these private objects. Drivers need to
implement object-specific funct
From: "Pandiyan, Dhinakaran"
Link bandwidth is shared between multiple display streams in DP MST
configurations. The DP MST topology manager structure maintains the
shared link bandwidth for a primary link directly connected to the GPU. For
atomic modesetting drivers, checking if there is suffici
Thanks Stephen. Looks good to me.
Logan
On 20/04/17 08:10 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in
> initializer
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/tee/tee_shm.c:87:2: error: unknown field 'kmap_atomic' specified in
initializer
.kmap_atomic = tee_shm_op_kmap_atomic,
^
drivers/tee/tee_shm.c:87:17: error: initialization from i
== Series Details ==
Series: drm: i915: Don't try detecting sinks on ports already in use
URL : https://patchwork.freedesktop.org/series/23299/
State : success
== Summary ==
Series 23299v1 drm: i915: Don't try detecting sinks on ports already in use
https://patchwork.freedesktop.org/api/1.0/se
On systems where more than one connector is attached to the same port,
the HPD pin is also shared, and attaching one connector will trigger a
hotplug on every other connector on that port. But, according to the
documentation, connectors sharing the port cannot be enabled
simultaneously, such that
On 19/04/17 03:49, Chris Wilson wrote:
On Tue, Apr 18, 2017 at 01:23:20PM -0700, Michel Thierry wrote:
From: Arun Siluvery
This change implements support for per-engine reset as an initial, less
intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset rec
== Series Details ==
Series: drm/i915: Fix pipe/transcoder enum mismatches
URL : https://patchwork.freedesktop.org/series/23296/
State : success
== Summary ==
Series 23296v1 drm/i915: Fix pipe/transcoder enum mismatches
https://patchwork.freedesktop.org/api/1.0/series/23296/revisions/1/mbox/
In several instances the driver passes an 'enum pipe' value to a
function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
TRANSCODER_x have the same values this doesn't cause functional
problems. Still it is incorrect and causes clang to generate warnings
like this:
drivers/gpu/drm/
On Thu, Apr 20, 2017 at 10:11 PM, Sean Paul wrote:
> Hi Dave,
> A few fixes for you to pick up. The driver changes are trivial, and the
> maintainer change was necessitated by the sti fix. The headliner here is the
> dma_buf_ops rename, since it touches so many drivers. Everything looks sane
> an
Hi Dave,
A few fixes for you to pick up. The driver changes are trivial, and the
maintainer change was necessitated by the sti fix. The headliner here is the
dma_buf_ops rename, since it touches so many drivers. Everything looks sane and
builds with that change, so it shouldn't cause problems.
dr
On Thu, Apr 20, 2017 at 07:19:50PM +0200, Peter Zijlstra wrote:
> Just for my sanity, could you confirm "tsc=unstable" (which requires the
> patch) actually works for you?
Also, could you get me the dmesg of a 'broken' boot?
___
Intel-gfx mailing list
On 20/04/17 09:39, Daniele Ceraolo Spurio wrote:
On 20/04/17 04:33, Joonas Lahtinen wrote:
On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote:
From: Arun Siluvery
GuC expects a list of registers from the driver which are saved/restored
during engine reset. The type of value to be save
On Tue, Apr 18, 2017 at 05:53:56PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 18, 2017 at 02:10:07PM +, Lofstedt, Marta wrote:
> > Sorry Peter, I still see regression on the Core2 machine, with your patch.
> >
>
> Blergh, ok. I'll see if I can dig out an actual Core2 machine somewhere.
> I sh
On 20/04/17 01:52, Chris Wilson wrote:
On Wed, Apr 19, 2017 at 06:09:00PM -0700, Michel Thierry wrote:
This patch is missing:
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index c1013af0b910..a8bdea43a217 100644
--- a/drivers/gpu/drm/i915/i915_
On 20/04/17 04:33, Joonas Lahtinen wrote:
On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote:
From: Arun Siluvery
GuC expects a list of registers from the driver which are saved/restored
during engine reset. The type of value to be saved is controlled by
flags. We provide a minimal set o
On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
> +static void
> +run_workload(unsigned int id, struct workload *wrk, unsigned int repeat,
> + enum intel_engine_id (*balance)(struct workload *wrk,
> + struct w
On Thu, Apr 20, 2017 at 03:34:56PM +0100, Tvrtko Ursulin wrote:
>
> On 20/04/2017 15:23, Chris Wilson wrote:
> >On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:
> >>+static void
> >>+alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb
> >>*b,
> >>+
On 20/04/2017 15:52, Chris Wilson wrote:
On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:
+ wrk->nr_bb[engine]++;
+
+ if (engine == VCS && balance) {
+ engine = balance(wrk, w);
+
On 19/04/2017 10:41, Chris Wilson wrote:
add/remove: 1/1 grow/shrink: 5/4 up/down: 391/-578 (-187)
function old new delta
execlists_submit_ports 262 471+209
port_assign.isra - 136+136
ca
On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:
> + wrk->nr_bb[engine]++;
> +
> + if (engine == VCS && balance) {
> + engine = balance(wrk, w);
> + wrk->nr_bb[engine]++;
> +
On Tue, 04 Apr 2017, Manasi Navare wrote:
> From: "Navare, Manasi D"
>
> Display stream compression is supported on DP 1.4 DP
> devices. This patch adds the corersponding DPCD
> register definitions for DSC.
>
> v4:
> * Add DSC Enable DPCD register def (Ander)
> v3:
> * Add some SHIFTS and MASKS
On 20/04/2017 15:33, Chris Wilson wrote:
On Thu, Apr 20, 2017 at 03:23:27PM +0100, Chris Wilson wrote:
You either want to reset presumed_offset=-1 each time, or better for all
concerned write the correct address alongside the seqno (which also
enables NORELOC).
Delta incoming.
See attached.
On 20/04/2017 15:23, Chris Wilson wrote:
On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:
+static void
+alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb *b,
+enum intel_engine_id engine, unsigned int flags)
+{
+ unsigned int bb_i, j
On Thu, Apr 20, 2017 at 03:23:27PM +0100, Chris Wilson wrote:
> You either want to reset presumed_offset=-1 each time, or better for all
> concerned write the correct address alongside the seqno (which also
> enables NORELOC).
>
> Delta incoming.
See attached.
Next concern is that I have full ri
On Thu, Apr 20, 2017 at 01:29:11PM +0100, Tvrtko Ursulin wrote:
> +static void
> +alloc_step_batch(struct workload *wrk, struct w_step *w, struct w_step_eb *b,
> + enum intel_engine_id engine, unsigned int flags)
> +{
> + unsigned int bb_i, j = 0;
> +
> + b->obj[j].handle = gem
On Thu, Apr 20, 2017 at 02:30:21PM +0100, Tvrtko Ursulin wrote:
>
> On 19/04/2017 10:41, Chris Wilson wrote:
> >If we attempt to wake up a waiter, who is currently checking the seqno
> >it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
> >However, it is actually awake and fu
On 19/04/2017 10:41, Chris Wilson wrote:
If we attempt to wake up a waiter, who is currently checking the seqno
it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
However, it is actually awake and functioning -- so delay reporting the
actual wake up until it sleeps.
v2: De
From: Tvrtko Ursulin
Tool which emits batch buffers to engines with configurable
sequences, durations, contexts, dependencies and userspace waits.
Unfinished but shows promise so sending out for early feedback.
v2:
* Load workload descriptors from files. (also -w)
* Help text.
* Calibration
On Thu, Apr 20, 2017 at 10:49:37AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Use discardable buffers for rings
> URL : https://patchwork.freedesktop.org/series/23274/
> State : failure
>
> == Summary ==
>
> Series 23274v1 drm/i915: Use discardable buffers for rings
>
On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote:
> From: Arun Siluvery
>
> GuC expects a list of registers from the driver which are saved/restored
> during engine reset. The type of value to be saved is controlled by
> flags. We provide a minimal set of registers that we want GuC to save
== Series Details ==
Series: drm/i915: Use discardable buffers for rings
URL : https://patchwork.freedesktop.org/series/23274/
State : failure
== Summary ==
Series 23274v1 drm/i915: Use discardable buffers for rings
https://patchwork.freedesktop.org/api/1.0/series/23274/revisions/1/mbox/
Test
On Wed, Apr 19, 2017 at 05:23:46PM +0300, Jani Nikula wrote:
> On Wed, 19 Apr 2017, Arkadiusz Hiler wrote:
> > On Wed, Apr 19, 2017 at 03:22:19PM +0300, Jani Nikula wrote:
> >> On Wed, 19 Apr 2017, Arkadiusz Hiler wrote:
> >> > We define gettid() using syscall() because glibc does not provide a
>
On to, 2017-04-20 at 11:17 +0100, Chris Wilson wrote:
> The contents of a ring are only valid between HEAD and TAIL, when the
> ring is idle (HEAD == TAIL) we can simply let the pages go under memory
> pressue if they are not pinned by an active context. And new content
> will be written and so the
On Wed, Apr 19, 2017 at 05:58:28PM +0100, Chris Wilson wrote:
> On Wed, Apr 19, 2017 at 01:01:50PM +0200, Arkadiusz Hiler wrote:
> > AOSP, as of this commit, does not include libdrm with fence defines.
>
> Pushed local defines that should keep the benchmark happy.
>
> Please do reset the configur
The contents of a ring are only valid between HEAD and TAIL, when the
ring is idle (HEAD == TAIL) we can simply let the pages go under memory
pressue if they are not pinned by an active context. And new content
will be written and so the ring will again be valid between HEAD and
TAIL, everything ou
On 19.04.2017 11:13, Petri Latvala wrote:
>
> The only Intel-specific part I can spot is that one chunk where you
> check for at-least-hsw. Is that so you can properly report skip
> instead of fail? It would be good to make this all suitable for
> non-Intel hw.
>
That is meant to report skip
On Wed, Apr 19, 2017 at 04:22:43PM -0700, Michel Thierry wrote:
> On 19/04/17 03:27, Chris Wilson wrote:
> >On Tue, Apr 18, 2017 at 01:23:29PM -0700, Michel Thierry wrote:
> >>This patch adds per engine reset and recovery (TDR) support when GuC is
> >>used to submit workloads to GPU.
> >>
> >>In th
On ke, 2017-04-19 at 10:41 +0100, Chris Wilson wrote:
> If we *know* that the engine is idle, i.e. we have not more contexts in
> lift, we can skip any spurious CSB idle interrupts. These spurious
in flight?
> interrupts seem to arrive long after we assert that the engines are
> completely idle,
On Wed, Apr 19, 2017 at 06:09:00PM -0700, Michel Thierry wrote:
> This patch is missing:
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index c1013af0b910..a8bdea43a217 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gp
On ke, 2017-04-19 at 10:41 +0100, Chris Wilson wrote:
> The major scaling bottleneck in execbuffer is the processing of the
> execobjects. Creating an auxiliary list is inefficient when compared to
> using the execobject array we already have allocated.
>
> Reservation is then split into phases. A
On 19-04-17 17:53, Daniel Vetter wrote:
> On Wed, Apr 12, 2017 at 12:50:04PM +0200, Maarten Lankhorst wrote:
>> intel_dp supports 3 properties, scaling mode, broadcast rgb and
>> force_audio. intel_digital_connector handles the plumbing,
>> so we only have to hook this up in compute_config and init
Hi All,
On 2017-04-20 09:51, Daniel Vetter wrote:
On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.
I'm personally trying to in
Signed-off-by: Abdiel Janulgue
---
lib/igt_core.c | 24
lib/igt_core.h | 3 +++
2 files changed, 27 insertions(+)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 8a7ba0d..e80a32a 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -329,6 +329,30 @@ static void _igt_l
Signed-off-by: Abdiel Janulgue
---
lib/igt_debugfs.c | 26 ++
lib/igt_debugfs.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 7584be5..b019c3b 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -22,6 +22,9 @@
*
Support executing external processes with the goal of capturing its
standard streams to the igt logging infrastructure in addition to its
exit status.
Cc: Daniel Vetter
Cc: Petri Latvala
Signed-off-by: Abdiel Janulgue
---
lib/igt_core.c | 151 +++
Converted:
- check_drm_clients (ensures no other clients are running.
functionality provided by drm_open_driver_master).
- debugfs_emon_crash
- debugfs_wedged
- drv_debugfs_reader
- sysfs_l3_parity
- test_rte_check (same as check_drm_clients)
- tools_test
- ZZ_check_dmesg
Cc: Daniel Ve
Hi Marek,
Thanks!
On 20 April 2017 at 13:36, Marek Szyprowski wrote:
> Hi All,
>
> On 2017-04-20 09:51, Daniel Vetter wrote:
>>
>> On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
>>>
>>> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
>>> in highmem.h, the
Hi Logan,
Thanks for the patch.
On 20 April 2017 at 13:21, Daniel Vetter wrote:
> On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
>> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
>> in highmem.h, the former can be aliased if any dma-buf user includes
>> t
On Wed, Apr 19, 2017 at 01:36:10PM -0600, Logan Gunthorpe wrote:
> Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
> in highmem.h, the former can be aliased if any dma-buf user includes
> that header.
>
> I'm personally trying to include highmem.h inside scatterlist.h and thi
On ke, 2017-04-19 at 10:41 +0100, Chris Wilson wrote:
> Avoid having too large a stack by creating the fake struct inode/file on
> the heap instead.
>
> drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
> drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 13
== Series Details ==
Series: drm/i915/scheduler: add gvt force-single-submission and notification
for guc (rev4)
URL : https://patchwork.freedesktop.org/series/21972/
State : success
== Summary ==
Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and
notification for guc
htt
Hi,
> == Series Details ==
>
> Series: drm/i915/scheduler: add gvt force-single-submission and notification
> for guc (rev4)
> URL : https://patchwork.freedesktop.org/series/21972/
> State : failure
>
> == Summary ==
>
> Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and
>
57 matches
Mail list logo
