Add pcode read/write emulation in gvt for BDW.
Signed-off-by: Weinan Li
---
drivers/gpu/drm/i915/gvt/handlers.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index
Hi,
This pull includes latest GVT-g fixes for 4.11 to resolve stablity
and usability issues found during co-debugging with distribution
developers which improves a lot.
Thanks.
---
The following changes since commit 4a0b3444da3ce1090d0f894f4e343756a94ab8c3:
drm/i915/gvt: return error code if
Reviewed-by: Sagar Arun Kamble
On 2/24/2017 4:41 AM, Michel Thierry wrote:
There was no way to check if the platform is running the latest firmware.
Cc: Tvrtko Ursulin
Cc: Arkadiusz Hiler
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gpu_error.c | 10 ++
1 file chan
On 23/02/17 08:38, Oscar Mateo wrote:
On 02/23/2017 11:14 AM, Michał Winiarski wrote:
We're always using all engines and kernel context for guc clients, let's
remove those arguments from guc_client_alloc.
I am quite new to the GuC but, by the look of it, passing the ctx was
groundwork for d
On Thu, 2017-02-16 at 09:09 +, Lankhorst, Maarten wrote:
> Daniel Vetter schreef op di 14-02-2017 om 20:51 [+0100]:
> > On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran
> > wrote:
> > > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
> > > > Pandiyan, Dhinakaran schreef op d
On 02/23/2017 11:14 AM, Michał Winiarski wrote:
We're always using all engines and kernel context for guc clients, let's
remove those arguments from guc_client_alloc.
I am quite new to the GuC but, by the look of it, passing the ctx was
groundwork for direct submission (which means calling guc
== Series Details ==
Series: drm/i915: Include GuC fw version in error state
URL : https://patchwork.freedesktop.org/series/20181/
State : success
== Summary ==
Series 20181v1 drm/i915: Include GuC fw version in error state
https://patchwork.freedesktop.org/api/1.0/series/20181/revisions/1/mbo
On Thu, Feb 23, 2017 at 08:57:54PM +, Chris Wilson wrote:
> On Thu, Feb 23, 2017 at 11:44:17AM -0800, Michel Thierry wrote:
> > +
> > + /* Make sure the active request will be marked as guilty */
> > + engine->hangcheck.stalled = true;
> > + engine->hangcheck.seqno
There was no way to check if the platform is running the latest firmware.
Cc: Tvrtko Ursulin
Cc: Arkadiusz Hiler
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gpu_error.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/driv
On Thu, Feb 23, 2017 at 10:26:29PM +, Chris Wilson wrote:
> On Thu, Feb 23, 2017 at 11:44:21AM -0800, Michel Thierry wrote:
> > Test watchdog triggered resets.
>
> How about setting a watchdog N with a dummy load set to expire in 2N
> (where 2N is less 1s to avoid hangcheck). Then check fence
On Thu, Feb 23, 2017 at 03:31:09PM -0500, Lyude Paul wrote:
> On Thu, 2017-02-23 at 07:26 +, Chris Wilson wrote:
> > On Wed, Feb 22, 2017 at 10:18:33PM -0500, Lyude wrote:
> > > Now that we can just disable HPD storm detection, there's no need
> > > to
> > > sleep between each hotplug cycle.
>
On Thu, Feb 23, 2017 at 05:39:24PM +, Vivi, Rodrigo wrote:
> Reviewed-by: Rodrigo Vivi
Thanks, applied. Just noticed the odd message when browsing the gvt logs.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
On Thu, Feb 23, 2017 at 11:44:21AM -0800, Michel Thierry wrote:
> Test watchdog triggered resets.
How about setting a watchdog N with a dummy load set to expire in 2N
(where 2N is less 1s to avoid hangcheck). Then check fence status to
ensure watchdog kicked the batch. See gem_exec_fence.
-Chris
On 23/02/17 13:49, Chris Wilson wrote:
On Thu, Feb 23, 2017 at 01:21:03PM -0800, Michel Thierry wrote:
On 23/02/17 12:57, Chris Wilson wrote:
On Thu, Feb 23, 2017 at 11:44:17AM -0800, Michel Thierry wrote:
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows
On Thu, Feb 23, 2017 at 01:21:03PM -0800, Michel Thierry wrote:
>
>
> On 23/02/17 12:57, Chris Wilson wrote:
> >On Thu, Feb 23, 2017 at 11:44:17AM -0800, Michel Thierry wrote:
> >>*** General ***
> >>
> >>Watchdog timeout (or "media engine reset") is a feature that allows
> >>userland application
On Thu, Feb 23, 2017 at 08:08:26PM +0100, Michał Winiarski wrote:
> +static void __execlists_try_preempt(struct intel_engine_cs *engine,
> + int prio)
> +{
> + struct drm_i915_gem_request *rq;
> + int highest_prio = INT_MIN;
> + int ret;
> +
> + spin_lo
On Thu, Feb 23, 2017 at 08:08:23PM +0100, Michał Winiarski wrote:
> Since request can be cancelled, we need to avoid overriding its priority
> during submission to be able to resubmit it.
And this breaks rescheduling.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
On 23/02/17 12:57, Chris Wilson wrote:
On Thu, Feb 23, 2017 at 11:44:17AM -0800, Michel Thierry wrote:
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself
On Thu, Feb 23, 2017 at 11:44:19AM -0800, Michel Thierry wrote:
> Final enablement patch for GPU hang detection using watchdog timeout.
> Using the gem_context_setparam ioctl, users can specify the desired
> timeout value in milliseconds, and the driver will do the conversion to
> 'timestamps'.
>
On Thu, Feb 23, 2017 at 11:44:18AM -0800, Michel Thierry wrote:
> Emit the required commands into the ring buffer for starting and
> stopping the watchdog timer before/after batch buffer start during
> batch buffer submission.
>
> Signed-off-by: Tomas Elf
> Signed-off-by: Ian Lister
> Signed-off
On Thu, Feb 23, 2017 at 11:44:17AM -0800, Michel Thierry wrote:
> *** General ***
>
> Watchdog timeout (or "media engine reset") is a feature that allows
> userland applications to enable hang detection on individual batch buffers.
> The detection mechanism itself is mostly bound to the hardware a
== Series Details ==
Series: series starting with [RFC,1/3] drm/i915: Watchdog timeout: IRQ handler
for gen8+
URL : https://patchwork.freedesktop.org/series/20173/
State : success
== Summary ==
Series 20173v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20173/r
On Thu, 2017-02-23 at 07:26 +, Chris Wilson wrote:
> On Wed, Feb 22, 2017 at 10:18:33PM -0500, Lyude wrote:
> > Now that we can just disable HPD storm detection, there's no need
> > to
> > sleep between each hotplug cycle.
> >
> > Signed-off-by: Lyude
> > ---
> > tests/chamelium.c | 5 ++---
Op 23-02-17 om 16:03 schreef Sean Paul:
> On Tue, Feb 21, 2017 at 02:51:40PM +0100, Maarten Lankhorst wrote:
>> It seems that nouveau requires this, so best to do this in the helper.
>> This allows nouveau to use the atomic suspend helper.
> Pardon the stupid question, but why can't nouveau just do
== Series Details ==
Series: series starting with [1/3] drm/i915: Refactor code to select the DDI
buf translation table (rev2)
URL : https://patchwork.freedesktop.org/series/20165/
State : success
== Summary ==
Series 20165v2 Series without cover letter
https://patchwork.freedesktop.org/api/1
Emit the required commands into the ring buffer for starting and
stopping the watchdog timer before/after batch buffer start during
batch buffer submission.
Signed-off-by: Tomas Elf
Signed-off-by: Ian Lister
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the only
thing that the driver needs to do to support this form of hang
Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in milliseconds, and the driver will do the conversion to
'timestamps'.
The _recommended_ default watchdog threshold for video engines is 60 ms,
s
Test watchdog triggered resets.
Signed-off-by: Michel Thierry
---
tests/drv_hangman.c | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
index 51bdbdaa..ba230f65 100644
--- a/tests/drv_hangman.c
+++ b/test
Set a watchdog timeout value in a given context.
Signed-off-by: Michel Thierry
---
lib/igt_gt.c | 7 +++
lib/igt_gt.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index 3bfaf2e4..e30385ec 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -40,6 +40,7 @@
#in
On 23/02/17 08:59, Chris Wilson wrote:
I915_RESET_IN_PROGRESS is being used for both signaling the requirement
to i915_mutex_lock_interruptible() to avoid taking the struct_mutex and
to instruct a waiter (already holding the struct_mutex) to perform the
reset. To allow for a little more coordin
We should probably do this conditionally, based on whether preemption is
actually enabled.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/intel_lrc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lr
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 10490bf..b71420c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/
Now that we're able to post-process the preemption event, let's actually
send it to GuC. To identify that preemption has finished, we're using a
dummy request sent through kernel_context.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_guc_submission.c | 90
From: Dave Gordon
This second client is created with priority KMD_HIGH, and marked
as preemptive.
v2: Rebase, cleanup, use an array for the second client.
Signed-off-by: Dave Gordon
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_debugfs.c| 8 +--
drivers/gpu/drm/i915/
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/intel_guc_fwif.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 25691f0..5b79ce0 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drive
We're always using all engines and kernel context for guc clients, let's
remove those arguments from guc_client_alloc.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_guc_submission.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/
We need to avoid sending new work if the preemption is in progress.
Once it finished, we need to identify and unsubmit the preempted
workload, submit new workload (potentially the one responsible for
preemption) and resubmit the preempted workload.
Signed-off-by: Michał Winiarski
---
drivers/gpu
We're only requesting preemption for requests that have high enough
priority (above threshold). Currently we're also ignoring requests that
have dependencies on different engines.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_guc_submission.c | 3 ++
drivers/gpu/drm/i915/intel_l
We're using engine->preempt_requested to mark that preemption has
started, and new hws entry allowing HW to mark that preemption has
finished and the engine is idle, allowing us to do the postprocessing.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/intel_ringbuffer.h | 10 ++
We're going to support preemption on platforms where GuC submission is
enabled.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_drv.c| 6 ++
drivers/gpu/drm/i915/i915_drv.h| 3 +++
drivers/gpu/drm/i915/i915_gem.c| 22 ++
Since request can be cancelled, we need to avoid overriding its priority
during submission to be able to resubmit it.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_guc_submission.c | 1 -
drivers/gpu/drm/i915/intel_lrc.c | 1 -
2 files changed, 2 deletions(-)
diff --gi
Now that we're able to unsubmit requests, let's try to actually preempt.
The series is partially based on "Preemption support for GPU scheduler":
https://lists.freedesktop.org/archives/intel-gfx/2015-December/082817.html
It requires "drm/i915/scheduler: Support user-defined priorities"
It's stil
== Series Details ==
Series: drm/i915: Split I915_RESET_IN_PROGRESS into two flags
URL : https://patchwork.freedesktop.org/series/20162/
State : success
== Summary ==
Series 20162v1 drm/i915: Split I915_RESET_IN_PROGRESS into two flags
https://patchwork.freedesktop.org/api/1.0/series/20162/rev
On Wed, Feb 22, 2017 at 02:59:28PM +0200, Ander Conselvan de Oliveira wrote:
> Handle DRM_DP_DUAL_MODE_LSPCON in drm_dp_get_dual_mode_type_name(),
> otherwise a call to that function can theoretically trigger a WARN.
>
> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
> Cc: Shas
On Wed, Feb 22, 2017 at 05:10:52PM +0200, Imre Deak wrote:
> At least a ParadTech PS175 LSPCON chip/firmware uses long instead of
> short pulses to signal output unplug/plug events. This is contrary to
> how branch devices normally work which use short HPD signaling. This
> chip will also switch to
== Series Details ==
Series: series starting with [1/5] drm/i915: Remove redundant TLB invalidate on
switching contexts
URL : https://patchwork.freedesktop.org/series/20155/
State : success
== Summary ==
Series 20155v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/seri
From: Ville Syrjälä
Rather than sprinkling ideas of how big the DDI buf translation tables
are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c
where the actual tables are defined. To that end we introduce
intel_ddi_dp_voltage_max() which will actually look at the proper
translati
On Thu, Feb 23, 2017 at 07:35:05PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Split the code to select the correct trasnslation table into DP,
translations, superfluous space before DP
> eDP and FDI specific helpers. This reduces the clutter in
> intel_prepare_dp_ddi
On Thu, Feb 23, 2017 at 07:44:48PM +0200, David Weinehall wrote:
> On Thu, Feb 23, 2017 at 07:35:07PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Rather than sprinkling ideas of how big the DDI buf translation tables
> > are somewhere in intel_dp.c, let's concentra
On Thu, Feb 23, 2017 at 07:43:52PM +0200, David Weinehall wrote:
> On Thu, Feb 23, 2017 at 07:35:06PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Convert the big switch statement in translate_signal_level() into a neat
> > table. The table also serves as documentat
On Thu, Feb 23, 2017 at 07:35:07PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Rather than sprinkling ideas of how big the DDI buf translation tables
> are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c
> where the actual tables are defined. To that end
On Thu, Feb 23, 2017 at 07:35:06PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Convert the big switch statement in translate_signal_level() into a neat
> table. The table also serves as documentation for the translation
> tables. We'll also have other uses for this table
Reviewed-by: Rodrigo Vivi
On Thu, 2017-02-23 at 12:20 +, Chris Wilson wrote:
> If the reserved region of memory has not been setup (most probably
> because it has been limited by hardware or virtualisation), don't tell
> the user to try and increase the amount of memory reserved for graphics.
From: Ville Syrjälä
Rather than sprinkling ideas of how big the DDI buf translation tables
are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c
where the actual tables are defined. To that end we introduce
intel_ddi_dp_voltage_max() which will actually look at the proper
translati
From: Ville Syrjälä
Convert the big switch statement in translate_signal_level() into a neat
table. The table also serves as documentation for the translation
tables. We'll also have other uses for this table later on.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 60
From: Ville Syrjälä
Split the code to select the correct trasnslation table into DP,
eDP and FDI specific helpers. This reduces the clutter in
intel_prepare_dp_ddi_buffers(), and we'll have other uses for some
of these new helper functions later on.
Signed-off-by: Ville Syrjälä
---
drivers/gp
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: signal first fence from irq
handler if complete
URL : https://patchwork.freedesktop.org/series/20153/
State : failure
== Summary ==
Series 20153v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/
On Thu, Feb 23, 2017 at 01:00:32PM +, Tvrtko Ursulin wrote:
>
> On 23/02/2017 12:01, Imre Deak wrote:
> >On Thu, Feb 23, 2017 at 09:37:29AM +, Tvrtko Ursulin wrote:
> >>[...]
> >>Having read the spec I think I see both sides now.
> >>
> >>Spec is actually suggesting we should busy-retry th
I915_RESET_IN_PROGRESS is being used for both signaling the requirement
to i915_mutex_lock_interruptible() to avoid taking the struct_mutex and
to instruct a waiter (already holding the struct_mutex) to perform the
reset. To allow for a little more coordination, split these two meaning
into a coupl
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c:454:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Signed-off-by: Fengguang Wu
---
tinydrm-helpers.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/tinyd
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 53a95c930ad728b11cc2b21e42b4bd9dcd306400
commit: 9f69eb5c36a644571cca6b2f8dc5f6a7cba04a8b [1827/1945] drm/tinydrm: Add
helper functions
coccinelle warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/tinydrm/core/tinydr
== Series Details ==
Series: drm/i915/execlists: Detect an out-of-order context switch
URL : https://patchwork.freedesktop.org/series/20150/
State : success
== Summary ==
Series 20150v1 drm/i915/execlists: Detect an out-of-order context switch
https://patchwork.freedesktop.org/api/1.0/series/2
We can simplify our tracking of pending writes in an execbuf to the
single bit in the vma->exec_entry->flags, but that requires the
relocation function knowing the object's vma. Pass it along.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 100 --
If the user requires patching of their batch or auxiliary buffers, we
currently make the alterations on the cpu. If they are active on the GPU
at the time, we wait under the struct_mutex for them to finish executing
before we rewrite the contents. This happens if shared relocation trees
are used be
i915_gem_stolen_list_info() sneakily takes advantage of the
obj->obj_exec_link to save itself from having to allocate. Enough of the
subterfuge, just allocate an array of pointers and sort them instead of
the list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 52
The only time we need to emit a flush inside request emission is after
an execbuffer, for which we can use the full __i915_add_request(). All
other instances want the simpler i915_add_request() without flushing, so
remove the useless helper.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/g
This has the benefit of not requiring us to manipulate the
vma->exec_link list when tearing down the execbuffer, and is a
marginally cheaper test to detect the user error.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_evict.c | 17 ++-
drivers/gpu/drm/i915/i915_gem_execb
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. As we lookup up the VMA, we
try and bind it back into active loca
Currently, the last object in the execlist is the always the batch.
However, when building the batch buffer we often know the batch object
first and if we can use the first slot in the execlist we can emit
relocation instructions relative to it immediately and avoid a separate
pass to adjust the re
When choosing a slot for an execbuffer, we ideally want to use the same
address as last time (so that we don't have to rebind it) and the same
address as expected by the user (so that we don't have to fixup any
relocations pointing to it). If we first try to bind the incoming
execbuffer->offset fro
Adding to the tail of the client request list as the only other user is
in the throttle ioctl that iterates forwards over the list. It only
needs protection against deletion of a request as it reads it, it simply
won't see a new request added to the end of the list, or it would be too
early and rej
Since obj->active_count is only updated upon retirement, if we see an
active object in the batch pool, double check that is still active
before deciding to allocate a new object.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 37 ++
1 fil
This simply hides the EAGAIN caused by userptr when userspace causes
resource contention. However, it is quite beneficial with highly
contended userptr users as we avoid repeating the setup costs and
kernel-user context switches.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c
Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
use to indicate that it wants the contents of this buffer preserved in
the error state (/sys/class/drm/cardN/error) following a GPU hang
involving this batch.
Use this at your discretion, the contents of the error state. alth
The advent of full-ppgtt lead to an extra indirection between the object
and its binding. That extra indirection has a noticeable impact on how
fast we can convert from the user handles to our internal vma for
execbuffer. In order to bypass the extra indirection, we use a
resizable hashtable to jum
Many eons ago, we add ppgtt support. Among the rejoicing, was a bitter
pill, it was slow, much slower due to driver overhead in looking up the
vma. In part this was due to obj_to_vma being a linear walk, but there
was also the effect in execbuf of going from handle to obj to vma, and
we have had ta
Combine the two slightly overlapping parameter structures we pass around
the execbuffer routines into one.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 560 -
1 file changed, 238 insertions(+), 322 deletions(-)
diff --git a/drivers/gpu
Currently the vma has one link member that is used for both holding its
place in the execbuf reservation list, and in any eviction list. This
dual property is quite tricky and error prone.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_evict.c | 14 ++---
drivers/gpu/
If we are setting the context and do inhibit the restoration from the
context image, also forgo applying the set-context w/a.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i
When switching between contexts using the aliasing_ppgtt, the VM is
shared. We don't need to reload the PD registers unless they are dirty.
Martin Peres reported an issue that looks like corruption between
Haswell context switches, bisecting to commit f9326be5f1d3 ("drm/i915:
Rearrange switch_cont
We are required to reload the TLBs around context switches
(MI_SET_CONTEXT specifically) and the recommendation is do that before
the MI_SET_CONTEXT so that it is serialised with the switch and not
forgotten:
[DevSNB] If Flush TLB invalidation Mode is enabled it’s the driver’s
responsibility to in
We are required to reload the TLBs around ppgtt switches. However, we
already do an unconditional TLB invalidate before every batch and a flush
afterwards, so this condition is already satisfied without extra flushes
around the LRI instructions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i9
No hardware was ever shipped that needed more than 4096 byte alignment
and future hardware will not use this legacy path. So reduce the
alignment to make it easier and quicker to launch workloads.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 17 -
dri
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt du
As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual
On Wed, Feb 22, 2017 at 04:36:31PM +, Robert Bragg wrote:
> Since the exponent for periodic OA counter sampling is maintained in a
> per-context register while we want to treat it as if it were global
> state we need to be able to safely issue an mmio write to a per-context
> register and affec
On Tue, Feb 21, 2017 at 02:51:42PM +0100, Maarten Lankhorst wrote:
> This introduces a slight behavioral change to rmfb. Instead of
> disabling a crtc when the primary plane is disabled, we try to
> preserve it.
>
> Apart from old versions of the vmwgfx xorg driver, there is
> nothing depending on
== Series Details ==
Series: drm/i915: Defer unmasking RPS interrupts until after making adjustments
URL : https://patchwork.freedesktop.org/series/20148/
State : success
== Summary ==
Series 20148v1 drm/i915: Defer unmasking RPS interrupts until after making
adjustments
https://patchwork.fre
On Thu, Feb 23, 2017 at 08:18:10AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v4,01/16] drm/i915: Check against the signaled
> bit for fences/requests
> URL : https://patchwork.freedesktop.org/series/20126/
> State : success
>
> == Summary ==
>
> Series 2
Think about two situations where:-
- Monitor supports scrambling and scdc, but we will not enable it, as
the current mode is 1080P@148 MHz
- Monitor supports scrambling and scdc, and we will enable it, as the
current mode is 4k@596 Mhz
To differentiate between these two, we have:
config->hdmi_s
On Tue, Feb 21, 2017 at 02:51:41PM +0100, Maarten Lankhorst wrote:
> Instead of trying to do everything in 1 go, just do a basic safe
> conversion first. We've been bitten by too many regressions in the
> past.
>
> This patch only converts drm_framebuffer_remove to atomic. The
> regression sensiti
On Tue, Feb 21, 2017 at 02:51:40PM +0100, Maarten Lankhorst wrote:
> It seems that nouveau requires this, so best to do this in the helper.
> This allows nouveau to use the atomic suspend helper.
Pardon the stupid question, but why can't nouveau just do the right thing when
crtc_state->active beco
== Series Details ==
Series: drm/i915: Distinguish between timeout and error in sideband transactions
URL : https://patchwork.freedesktop.org/series/20147/
State : warning
== Summary ==
Series 20147v1 drm/i915: Distinguish between timeout and error in sideband
transactions
https://patchwork.f
We require that the request is completed before the context is switched
away.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8b64af63f914..a331fd36992f
To make our adjustments to RPS requires taking a mutex and potentially
sleeping for an unknown duration - until we have completed our
adjustments further RPS interrupts are immaterial (they are based on
stale thresholds) and we can safely ignore them.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
After initiating a sideband transaction, we only want to wait for the
transaction to become idle. If, as we are, we wait for both the busy
and error flag to clear, if an error is raised we just spin until the
timeout. Once the hw is idle, we can then check to see if the hw flagged
an error, and rep
This test case introduces concurrently running test cases for atomic
modesetting.
The first test or thread draws blue backround with black holes on it.
These holes are covered by rectangular, blue planes that are placed
randomly like in test case 'kms_plane_multiple'.
The second thread changes re
On Thu, 2017-02-23 at 07:52 +, Patchwork wrote:
> == Series Details ==
>
> Series: GLK plane/scaling fixes (rev2)
> URL : https://patchwork.freedesktop.org/series/20051/
> State : success
Pushed. Thanks for reviewing.
Ander
>
> == Summary ==
>
> Series 20051v2 GLK plane/scaling fixes
>
On Thu, Feb 23, 2017 at 03:07:40PM +0200, Ander Conselvan De Oliveira wrote:
> On Thu, 2017-02-23 at 16:33 +0530, Sharma, Shashank wrote:
> > Thanks for the review Ander, my comments, inline.
> >
> >
> > Regards
> >
> > Shashank
> >
> >
> > On 2/23/2017 1:33 PM, Ander Conselvan De Oliveira wro
1 - 100 of 141 matches
Mail list logo
