== Series Details ==
Series: drm/i915/gvt: Deliver guest cursor hotspot info (rev3)
URL : https://patchwork.freedesktop.org/series/41727/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4172_full -> Patchwork_8992_full =
== Summary - WARNING ==
Minor unknown changes coming
Quoting Lionel Landwerlin (2018-05-11 16:43:02)
> On 11/05/18 15:18, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2018-05-11 15:14:13)
> >> My understanding of the virtual memory addressing from the GPU is
> >> limited...
> >> But how can the GPU poke at the kernel's allocated data?
> >> I t
Signed-off-by: Chris Wilson
---
lib/igt_audio.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/lib/igt_audio.c b/lib/igt_audio.c
index 2321d1c6e..229ce6c69 100644
--- a/lib/igt_audio.c
+++ b/lib/igt_audio.c
@@ -266,9 +266,7 @@ bool audio_signal_detect(struct audio_signal *
We already call x11_position() to calculate the position of the
overlay, so do not need to manually recompute them inside
x11_overlay_create(). This has the advantage that x11_position()
understands the multi-monitor layout instructions.
Signed-off-by: Chris Wilson
---
overlay/x11/x11-overlay.c
If we trigger "too many" resets, the context and even the file, will be
banend and subsequent execbufs should fail with -EIO.
Signed-off-by: Chris Wilson
---
tests/gem_eio.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/tests/gem_eio.c b/t
From: Tvrtko Ursulin
We want to make sure RT tasks which use a lot of CPU times can submit
batch buffers with roughly the same latency (and certainly not worse)
compared to normal tasks.
v2: Add tests to run across all engines simultaneously to encourage
ksoftirqd to kick in even more often.
Si
trigger_reset() imposes a tight time constraint (2s) so that we verify
that the reset itself completes quickly. In the middle of this check, we
call gem_quiescent_gpu() which may invoke an rcu_barrier() or two to
clear out the freed memory (DROP_FREED). Those barriers may have
unbounded latency pus
The test wrote to the same dwords from multiple contexts, assuming that
the writes would be ordered by its submission. However, as it was using
multiple contexts without a write hazard, those timelines are not
coupled and the requests may be emitted to hw in any order. So emit a
write hazard for ea
On Mon, 14 May 2018, Zhi Wang wrote:
> The following changes since commit 0c79f9cb77eae28d48a4f9fc1b3341aacbbd260c:
>
>drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk (2018-05-13
> 10:29:44 +0100)
>
> are available in the git repository at:
>
>https://github.com/intel/gvt-linux.
Chris Wilson writes:
> Quoting Chris Wilson (2018-05-11 13:11:47)
>> The original switch to use CSB from the HWSP was plagued by the effort
>> of read ordering on VT-d; we would read the WRITE pointer from the HWSP
>> before it had completed writing the CSB contents. The mystery comes down
>> to
Quoting Mika Kuoppala (2018-05-14 09:33:23)
> Chris Wilson writes:
>
> > Quoting Chris Wilson (2018-05-11 13:11:47)
> >> The original switch to use CSB from the HWSP was plagued by the effort
> >> of read ordering on VT-d; we would read the WRITE pointer from the HWSP
> >> before it had completed
On Fri, 11 May 2018, Dhinakaran Pandiyan wrote:
> PSR hardware and hence the driver code for VLV and CHV deviates a lot from
> their DDI counterparts. While the feature has been disabled for a long time
> now, retaining support for these platforms is a maintenance burden. There
> have been multipl
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
On Wed, 09 May 2018, Ramalingam C wrote:
> GMBUS HW supports 511Bytes as Max Bytes per single RD/WR op. Instead of
> enabling the 511Bytes per RD/WR cycle on legacy platforms for no
> absolute ROIs, this change allows the max bytes per op upto 511Bytes
> from Gen9 onwards.
>
> v2:
> No Change.
>
On Fri, 11 May 2018, "Kumar, Abhay" wrote:
> On 5/11/2018 5:33 AM, Ville Syrjälä wrote:
>> On Wed, May 09, 2018 at 06:25:32PM -0700, Abhay Kumar wrote:
>>> From: Ville Syrjälä
>>>
>>> CDCLK has to be at least twice the BLCK regardless of audio. Audio
>>> driver has to probe using this hook and in
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
If inside hangcheck we see that the engine has paused, but there is an
execlists interrupt still pending, we know that the tasklet did not
fire. Dump the GEM trace along with the current engine state, and kick
the tasklet to recovery without having to go through a GPU reset.
Signed-off-by: Chris W
Store whether or not we need to kick the guc's execlists emulation on
the engine itself to avoid chasing the device info.
gen8_cs_irq_handler 512 428 -84
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/int
When we process the outstanding requests upon banning a context, we need
to acquire both the engine and the client's timeline, nesting the locks.
This requires explicit markup as the two timelines are now of the same
class, since commit a89d1f921c15 ("drm/i915: Split i915_gem_timeline into
individu
In the next few patches, we want to abuse tasklet to avoid ksoftirqd
latency along critical paths. To make that abuse easily to swallow,
first coat the tasklet in a little syntactic sugar.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
dr
Continuing the theme of bypassing ksoftirqd latency, also first try to
directly submit from the CS interrupt handler to clear the ELSP and
queue the next.
In the past, we have been hesitant to do this as the context switch
processing has been quite heavy, requiring forcewaked mmio. However, as
we
Bypass using the tasklet to submit the first request to HW, as the
tasklet may be deferred unto ksoftirqd and at a minimum will add in
excess of 10us (and maybe tens of milliseconds) to our execution
latency. This latency reduction is most notable when execution flows
between engines.
v2: Beware h
We rely on ksoftirqd to run in a timely fashion in order to drain the
execlists queue. Quite frequently, it does not. In some cases we may see
latencies of over 200ms triggering our idle timeouts and forcing us to
declare the driver wedged!
Thus we can speed up idle detection by bypassing ksoftirq
The idea was to try and let the existing tasklet run to completion
before we began the reset, but it involves a racy check against anything
else that tries to run the tasklet. Rather than acknowledge and ignore
the race, let it be and don't try and be too clever.
The tasklet will resume execution
Continuing the discussion with the latest refactorings, however I ran
some tests to measure the impact on system (!i915) latency,
using igt/benchmarks/gem_syslatency -t 120
drm-tip:
latency mean=1.211us max=10us (no load)
latency mean=2.611us max=83us (i915)
latency mean=1
After using direct submission from the irq handler, it is very likely
that the ENGINE_IRQ_EXECLISTS bit is unset and so we do not need to
test it first. It also follows that we then want to do a direct
submission evertime the irq_posted bit is set, and can use that as our
boolean rather than a sepa
When setting up reset, we may need to recursively prepare an engine. In
which case we should only synchronously flush the tasklets on the outer
most call, the inner calls will then be inside an atomic section where
the tasklet will never be run (and so the sync will never complete).
Signed-off-by:
== Series Details ==
Series: series starting with [01/10] drm/i915: Mark up nested spinlocks
URL : https://patchwork.freedesktop.org/series/43123/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c01ec3ff8d8e drm/i915: Mark up nested spinlocks
677445fc5fa2 drm/i915: Remove tasklet
== Series Details ==
Series: series starting with [01/10] drm/i915: Mark up nested spinlocks
URL : https://patchwork.freedesktop.org/series/43123/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Mark up nested spinlocks
Okay!
Commit: drm/i915: Remove tasklet flush
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
== Series Details ==
Series: series starting with [01/10] drm/i915: Mark up nested spinlocks
URL : https://patchwork.freedesktop.org/series/43123/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4175 -> Patchwork_8993 =
== Summary - WARNING ==
Minor unknown changes coming
On 14/05/2018 10:37, Chris Wilson wrote:
When we process the outstanding requests upon banning a context, we need
to acquire both the engine and the client's timeline, nesting the locks.
This requires explicit markup as the two timelines are now of the same
class, since commit a89d1f921c15 ("drm
On 14/05/2018 10:37, Chris Wilson wrote:
Continuing the discussion with the latest refactorings, however I ran
some tests to measure the impact on system (!i915) latency,
using igt/benchmarks/gem_syslatency -t 120
drm-tip:
latency mean=1.211us max=10us (no load)
latency mean=2.6
On 14/05/2018 09:02, Chris Wilson wrote:
We already call x11_position() to calculate the position of the
overlay, so do not need to manually recompute them inside
x11_overlay_create(). This has the advantage that x11_position()
understands the multi-monitor layout instructions.
Signed-off-by: C
On 14/05/2018 09:02, Chris Wilson wrote:
Signed-off-by: Chris Wilson
---
lib/igt_audio.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/lib/igt_audio.c b/lib/igt_audio.c
index 2321d1c6e..229ce6c69 100644
--- a/lib/igt_audio.c
+++ b/lib/igt_audio.c
@@ -266,9 +266,7 @@
On Fri, 30 Mar 2018 10:31:52 +0200, Sagar Arun Kamble
wrote:
Host to GuC actions for SLPC receive additional data as output through
scratch registers currently. intel_guc_send_and_receive handles this.
We need to define SLPC specific Host to GuC send action (slpc_send) as
wrapper on top of it
Quoting Tvrtko Ursulin (2018-05-14 11:11:54)
>
> On 14/05/2018 10:37, Chris Wilson wrote:
> > Continuing the discussion with the latest refactorings, however I ran
> > some tests to measure the impact on system (!i915) latency,
> > using igt/benchmarks/gem_syslatency -t 120
> >
> > drm-tip:
> >
On 14/05/2018 10:37, Chris Wilson wrote:
Store whether or not we need to kick the guc's execlists emulation on
the engine itself to avoid chasing the device info.
gen8_cs_irq_handler 512 428 -84
Impressive, or not, depends whether you look at the saving or cod
On Fri, 30 Mar 2018 10:31:53 +0200, Sagar Arun Kamble
wrote:
From: Tom O'Rourke
Send SLPC shutdown event during uc_fini_hw or prior to enabling SLPC
done while communicating updated parameters in shared data.
v1: Return void instead of ignored error code (Paulo). Removed WARN_ON
for ch
Quoting Chris Wilson (2018-05-12 09:49:57)
> When we process the outstanding requests upon banning a context, we need
> to acquire both the engine and the client's timeline, nesting the locks.
> This requires explicit markup as the two timelines are now of the same
> class, since commit a89d1f921c1
Quoting Chris Wilson (2018-05-14 11:43:44)
> Quoting Chris Wilson (2018-05-12 09:49:57)
> > When we process the outstanding requests upon banning a context, we need
> > to acquire both the engine and the client's timeline, nesting the locks.
> > This requires explicit markup as the two timelines ar
Extend the i915 load to (optionally) pass a write hazard between
engines, causing us to wait on the interrupt between engines. Thus
adding MI_USER_INTERRUPT irq handling to our list of sins.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
benchmarks/gem_syslatency.c | 28 ++--
On 14/05/2018 09:02, Chris Wilson wrote:
The test wrote to the same dwords from multiple contexts, assuming that
the writes would be ordered by its submission. However, as it was using
multiple contexts without a write hazard, those timelines are not
coupled and the requests may be emitted to hw
On 14/05/2018 09:02, Chris Wilson wrote:
If we trigger "too many" resets, the context and even the file, will be
banend and subsequent execbufs should fail with -EIO.
banned
Signed-off-by: Chris Wilson
---
tests/gem_eio.c | 49 +
1 file ch
On 14/05/2018 09:02, Chris Wilson wrote:
trigger_reset() imposes a tight time constraint (2s) so that we verify
that the reset itself completes quickly. In the middle of this check, we
call gem_quiescent_gpu() which may invoke an rcu_barrier() or two to
clear out the freed memory (DROP_FREED). T
Quoting Tvrtko Ursulin (2018-05-14 12:03:58)
>
> On 14/05/2018 09:02, Chris Wilson wrote:
> > trigger_reset() imposes a tight time constraint (2s) so that we verify
> > that the reset itself completes quickly. In the middle of this check, we
> > call gem_quiescent_gpu() which may invoke an rcu_bar
On 14/05/2018 09:02, Chris Wilson wrote:
From: Tvrtko Ursulin
We want to make sure RT tasks which use a lot of CPU times can submit
batch buffers with roughly the same latency (and certainly not worse)
compared to normal tasks.
v2: Add tests to run across all engines simultaneously to encoura
Quoting Tvrtko Ursulin (2018-05-14 12:13:10)
>
> On 14/05/2018 09:02, Chris Wilson wrote:
> > From: Tvrtko Ursulin
> >
> > We want to make sure RT tasks which use a lot of CPU times can submit
> > batch buffers with roughly the same latency (and certainly not worse)
> > compared to normal tasks.
On Fri, 30 Mar 2018 10:31:55 +0200, Sagar Arun Kamble
wrote:
SLPC behavior can be changed through set of parameters. These parameters
can be updated and queried from i915 though Host to GuC SLPC events. This
patch adds parameter update events for setting/unsetting/getting params.
Setting para
Quoting Tvrtko Ursulin (2018-05-14 11:27:56)
>
> On 14/05/2018 10:37, Chris Wilson wrote:
> > Store whether or not we need to kick the guc's execlists emulation on
> > the engine itself to avoid chasing the device info.
> >
> > gen8_cs_irq_handler 512 428 -84
>
>
On Fri, 30 Mar 2018 10:31:57 +0200, Sagar Arun Kamble
wrote:
From: Tom O'Rourke
Adds debugfs hooks for enabling/disabling each SLPC task.
The enable/disable debugfs files are:
i915_guc_slpc_gtperf, i915_guc_slpc_balancer, and i915_guc_slpc_dcc.
Each of these can take the values: "default"
On Fri, 30 Mar 2018 10:31:59 +0200, Sagar Arun Kamble
wrote:
Add support to set/read parameters and unset the parameters which will
revert them to default SLPC internal values. Explicit SLPC reset is
needed
on setting/unsetting some of the parameters.
This patch adds two debugfs interface
Thanks for the reminder! :)
Thanks,
Zhi.
-Original Message-
From: Nikula, Jani
Sent: Monday, May 14, 2018 11:36 AM
To: Wang, Zhi A ; Zhenyu Wang ;
Joonas Lahtinen ; Vivi, Rodrigo
Cc: intel-gfx ; intel-gvt-dev
; Lv, Zhiyuan ;
Yuan, Hang
Subject: Re: [PULL] gvt-next for 4.18
On Mon,
== Series Details ==
Series: benchmarks/gem_syslatency: Pass a write hazard around
URL : https://patchwork.freedesktop.org/series/43126/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4176 -> IGTPW_1353 =
== Summary - WARNING ==
Minor unknown changes coming with IGTPW_135
On Fri, 30 Mar 2018 10:32:01 +0200, Sagar Arun Kamble
wrote:
When SLPC is controlling frequency requests, RPS state related to
autotuning is no longer valid. Make user aware through banner
upfront. Value read from register RPNSWREQ likely has the frequency
requested last by GuC SLPC.
v1: Rep
== Series Details ==
Series: series starting with [01/10] drm/i915: Mark up nested spinlocks
URL : https://patchwork.freedesktop.org/series/43123/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4175_full -> Patchwork_8993_full =
== Summary - WARNING ==
Minor unknown chang
On Sun, 29 Apr 2018, Tarun Vyas wrote:
> From: Tarun
Please use your full name. This will appear in git logs.
> The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then
> the pipe_update_start call schedules itself out to check back later.
>
> On ChromeOS-4.4 kernel, which is fairl
Hi all,
The following changes tagged drm-intel-testing-2018-05-14:
drm-intel-next-2018-05-14:
Last drm/i915 changes for v4.18:
- NV12 enabling (Chandra, Maarten)
- ICL workarounds (Oscar)
- ICL basic DPLL enabling (Paulo)
- GVT updates
- DP link config refactoring (Jani)
- Module parameter to ov
On 12/05/18 02:03, Chris Wilson wrote:
If we trigger "too many" resets, the context and even the file, will be
banend and subsequent execbufs should fail with -EIO.
Signed-off-by: Chris Wilson
Does this replace gem_reset_stats@test_ban?
Thanks,
Antonio
_
Quoting Chris Wilson (2018-05-14 11:25:45)
> Quoting Tvrtko Ursulin (2018-05-14 11:11:54)
> >
> > On 14/05/2018 10:37, Chris Wilson wrote:
> > > Continuing the discussion with the latest refactorings, however I ran
> > > some tests to measure the impact on system (!i915) latency,
> > > using igt/b
Quoting Antonio Argenziano (2018-05-14 15:51:04)
>
>
> On 12/05/18 02:03, Chris Wilson wrote:
> > If we trigger "too many" resets, the context and even the file, will be
> > banend and subsequent execbufs should fail with -EIO.
> >
> > Signed-off-by: Chris Wilson
>
> Does this replace gem_rese
Quoting Tvrtko Ursulin (2018-05-14 11:59:09)
>
> On 14/05/2018 09:02, Chris Wilson wrote:
> > The test wrote to the same dwords from multiple contexts, assuming that
> > the writes would be ordered by its submission. However, as it was using
> > multiple contexts without a write hazard, those time
Thank you for the review comments Uma Shankar!
On Wednesday 09 May 2018 03:31 PM, Shankar, Uma wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-gfx@lists.freedesktop.org;
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in
From: Chris Wilson
Currently we only configure the power gating for Skylake and above, but
the configuration should equally apply to Broadwell and Braswell. Even
though, there is not as much variation as for later generations, we want
to expose control over the configuration to userspace and may
From: Chris Wilson
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration pe
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf
Hi,
This is a different approach to the perf & powergating interaction
problem. In this version we basically disable powergating when
i915/perf is on. We do something similar already in that we disable
RC6 for similar reasons.
Cheers,
Chris Wilson (3):
drm/i915: Program RPCS for Broadwell
dr
From: Chris Wilson
We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
This can be used to monitor the number of powergating transition
changes for a particular workload.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
drivers/gpu/drm/i915/intel_lrc.c| 16 +++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 12 +
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 94466aeafd02..fc5b5d66abcd 100644
--- a/drivers/gp
On Wednesday 09 May 2018 03:36 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
seanp...@chro
== Series Details ==
Series: drm/i915: per context slice/subslice powergating (rev4)
URL : https://patchwork.freedesktop.org/series/42285/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d66d43edbd8d drm/i915: Program RPCS for Broadwell
61ad4a566887 drm/i915: Record the sseu conf
== Series Details ==
Series: drm/i915: per context slice/subslice powergating (rev4)
URL : https://patchwork.freedesktop.org/series/42285/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Program RPCS for Broadwell
Okay!
Commit: drm/i915: Record the sseu configurati
== Series Details ==
Series: drm/i915: per context slice/subslice powergating (rev4)
URL : https://patchwork.freedesktop.org/series/42285/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4178 -> Patchwork_8994 =
== Summary - WARNING ==
Minor unknown changes coming with Pat
Factor in clear values wherever required while updating destination
min/max.
References: HSDES#160184
Signed-off-by: Michel Thierry
Cc: mesa-...@lists.freedesktop.org
Cc: Mika Kuoppala
Cc: Oscar Mateo
Reviewed-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Link:
https://patchwork.freedesk
On Mon, 2018-05-14 at 12:09 +0300, Jani Nikula wrote:
> On Fri, 11 May 2018, Dhinakaran Pandiyan om> wrote:
> >
> > PSR hardware and hence the driver code for VLV and CHV deviates a
> > lot from
> > their DDI counterparts. While the feature has been disabled for a
> > long time
> > now, retaining
From: Ville Syrjälä
Clean up the ADPA pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
v2: Order the defines shift,mask,value (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
d
From: Ville Syrjälä
Clean up the LVDS pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
v2: Order the defines shift,mask,value (Jani)
Drop ruperfluous braces and whitesapce changes (Jani)
C
From: Ville Syrjälä
Parametrize the DVO pipe select bits.
For consistency with the new way of doing things, let's read out the
pipe select bits even when the port is disable, even though we don't
need that behaviour for asserts in this case.
v2: Order the defines shift,mask,value (Jani)
Review
From: Ville Syrjälä
Parametrize the TV pipe select bits.
For consistency with the new way of doing things, let's read out the
pipe select bits even when the port is disable, even though we don't
need that behaviour for asserts in this case.
v2: Order the defines shift,mask,value (Jani)
Clea
From: Ville Syrjälä
Clean up the SDVO pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
v2: Order the defines shift,mask,value (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
d
== Series Details ==
Series: benchmarks/gem_syslatency: Pass a write hazard around
URL : https://patchwork.freedesktop.org/series/43126/
State : failure
== Summary ==
= CI Bug Log - changes from IGT_4477_full -> IGTPW_1353_full =
== Summary - FAILURE ==
Serious unknown changes coming with
== Series Details ==
Series: drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk (rev2)
URL : https://patchwork.freedesktop.org/series/43024/
State : failure
== Summary ==
Applying: drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk
error: Failed to merge in the changes.
Using ind
== Series Details ==
Series: series starting with [1/5] drm/i915: Clean up ADPA pipe select bits
URL : https://patchwork.freedesktop.org/series/43151/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
afd2d93c4687 drm/i915: Clean up ADPA pipe select bits
-:32: CHECK:SPACING: spaces
== Series Details ==
Series: series starting with [1/5] drm/i915: Clean up ADPA pipe select bits
URL : https://patchwork.freedesktop.org/series/43151/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4179 -> Patchwork_8996 =
== Summary - FAILURE ==
Serious unknown changes c
From: Ville Syrjälä
Clean up the LVDS pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
v2: Order the defines shift,mask,value (Jani)
Drop ruperfluous braces and whitesapce changes (Jani)
C
On Tue, May 08, 2018 at 10:44:56AM +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> Added content_type property to drm_connector_state
> in order to properly handle external HDMI TV content-type setting.
>
> v2:
> * Moved helper function which attaches content type property
>to the drm
== Series Details ==
Series: series starting with [1/5] drm/i915: Clean up ADPA pipe select bits
(rev2)
URL : https://patchwork.freedesktop.org/series/43151/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
eedc0c805469 drm/i915: Clean up ADPA pipe select bits
-:32: CHECK:SPACING
On 8 May 2018 at 10:05, wrote:
> From: Changbin Du
>
> Finally, this add the first huge gtt support for GVTg - 64K pages. Since
> 64K page and 4K page cannot be mixed on the same page table, so we always
> split a 64K entry into small 4K page. And when unshadow guest 64K entry,
> we need ensure
On 14/05/18 08:02, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-05-14 15:51:04)
On 12/05/18 02:03, Chris Wilson wrote:
If we trigger "too many" resets, the context and even the file, will be
banend and subsequent execbufs should fail with -EIO.
Signed-off-by: Chris Wilson
Does t
intel_pipe_update_start also needs to wait for PSR to idle
out. Need some minor modifications in psr_wait_for_idle in
order to reuse it.
Cc: Chris Wilson
Signed-off-by: Tarun Vyas
---
drivers/gpu/drm/i915/intel_psr.c | 29 ++---
1 file changed, 18 insertions(+), 11 delet
The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then
the pipe_update_start call schedules itself out to check back later.
On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but
lags w.r.t core kernel code, hot plugging an external display triggers
tons of "potential
We have new users (follow up patch). So, un-statify it
Cc: Chris Wilson
Signed-off-by: Tarun Vyas
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm
We call i915_gem_reset_prepare_engine() during reset and then upon
wedging if the reset fails. Unfortunately, kthread_park and similar do
not support being called recursively and so we must count the number of
times we prepare for reset and only actually prepare on the outermost
layer. (Similarly f
Quoting Chris Wilson (2018-05-14 21:52:13)
> We call i915_gem_reset_prepare_engine() during reset and then upon
> wedging if the reset fails. Unfortunately, kthread_park and similar do
> not support being called recursively and so we must count the number of
> times we prepare for reset and only ac
The idea was to try and let the existing tasklet run to completion
before we began the reset, but it involves a racy check against anything
else that tries to run the tasklet. Rather than acknowledge and ignore
the race, let it be and don't try and be too clever.
The tasklet will resume execution
As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.
v2: And do the same for the guc.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Michał Winiarski
Revi
In the next few patches, we want to abuse tasklet to avoid ksoftirqd
latency along critical paths. To make that abuse easily to swallow,
first coat the tasklet in a little syntactic sugar.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
dr
1 - 100 of 147 matches
Mail list logo
