Quoting Tvrtko Ursulin (2019-02-28 07:56:20)
>
> On 27/02/2019 23:09, Chris Wilson wrote:
> > We currently use a worker queued from an rcu callback to determine when
> > a how grace period has elapsed while we remained idle. We use this idle
> > delay to infer that we will be idle for a while and
Quoting Tvrtko Ursulin (2019-02-28 07:43:41)
>
> On 26/02/2019 10:23, Chris Wilson wrote:
> > A simple mutex used for guarding the flow of requests in and out of the
> > timeline. In the short-term, it will be used only to guard the addition
> > of requests into the timeline, taken on alloc and re
We currently use a worker queued from an rcu callback to determine when
a how grace period has elapsed while we remained idle. We use this idle
delay to infer that we will be idle for a while and this is a suitable
point at which we can trim our global memory caches.
Since we wrote that, this mech
== Series Details ==
Series: series starting with [1/3] drm/i915: Make request allocation caches
global (rev2)
URL : https://patchwork.freedesktop.org/series/57319/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8a14917577db drm/i915: Make request allocation caches global
-:163
Chris Wilson writes:
> This reverts commit 0b702dca26580e3bbfbbaf22dfc29280b6263414.
>
> CI reports that this is not as reliable as it first appears, with
> failures starting to sporadically occur in selftests.
>
> Fixes: 0b702dca2658 ("drm/i915: Avoid waking the engines just to check if
> they
== Series Details ==
Series: series starting with [1/3] drm/i915: Make request allocation caches
global (rev2)
URL : https://patchwork.freedesktop.org/series/57319/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make request allocation cache
Chris Wilson writes:
> If we have parked, then we must have passed an idleness test and still
> be idle. We chose not to use this shortcut in the past so that we could
> use the idleness test at any time and inspect HW. However, some HW like
> Sandybridge, doesn't like being woken up frivolously,
On Wed, Feb 27, 2019 at 04:45:32PM +0100, Hans de Goede wrote:
> Hi,
>
> On 27-02-19 12:16, Jani Nikula wrote:
> > On Wed, 27 Feb 2019, Heikki Krogerus
> > wrote:
> > > One thing that this series does not consider is the DP lane count
> > > problem. The GPU drivers (i915 in this case) does not k
Quoting Mika Kuoppala (2019-02-28 09:08:21)
> Chris Wilson writes:
>
> > If we have parked, then we must have passed an idleness test and still
> > be idle. We chose not to use this shortcut in the past so that we could
> > use the idleness test at any time and inspect HW. However, some HW like
>
== Series Details ==
Series: series starting with [1/3] drm/i915: Make request allocation caches
global (rev2)
URL : https://patchwork.freedesktop.org/series/57319/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5670 -> Patchwork_12325
=
On 28/02/2019 08:29, Chris Wilson wrote:
We currently use a worker queued from an rcu callback to determine when
a how grace period has elapsed while we remained idle. We use this idle
delay to infer that we will be idle for a while and this is a suitable
point at which we can trim our global me
Quoting Tvrtko Ursulin (2019-02-28 09:38:36)
>
> On 28/02/2019 08:29, Chris Wilson wrote:
> > @@ -143,7 +141,15 @@ static u32 __i915_gem_park(struct drm_i915_private
> > *i915)
> >
> > intel_display_power_put(i915, POWER_DOMAIN_GT_IRQ, wakeref);
> >
> > - return i915->gt.epoch;
>
On 28/02/2019 09:43, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-02-28 09:38:36)
On 28/02/2019 08:29, Chris Wilson wrote:
@@ -143,7 +141,15 @@ static u32 __i915_gem_park(struct drm_i915_private *i915)
intel_display_power_put(i915, POWER_DOMAIN_GT_IRQ, wakeref);
- retur
Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38)
> On 2019-02-12 17:28:57 [+0100], To linux-ker...@vger.kernel.org wrote:
> > The timer is initialized with TIMER_IRQSAFE flag. It does look like the
> > timer callback requires this flag at all. Its sole purpose is to ensure
> > synchronisatio
Quoting Tvrtko Ursulin (2019-02-28 09:55:46)
>
> On 28/02/2019 09:43, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-02-28 09:38:36)
> >>
> >> On 28/02/2019 08:29, Chris Wilson wrote:
> >>> @@ -143,7 +141,15 @@ static u32 __i915_gem_park(struct drm_i915_private
> >>> *i915)
> >>>
> >>>
On Thu, 28 Feb 2019, Michal Wajdeczko wrote:
> On Wed, 27 Feb 2019 18:02:36 +0100, Jani Nikula
> wrote:
>
>> @@ -116,6 +116,34 @@
>> * #define GEN8_BAR_MMIO(0xb888)
>> */
>> +/**
>> + * REG_BIT() - Prepare a u32 bit value
>> + * @__n: 0-based bit number
>> + *
>> + * Lo
Quoting Jani Nikula (2019-02-28 10:07:06)
> On Thu, 28 Feb 2019, Michal Wajdeczko wrote:
> > On Wed, 27 Feb 2019 18:02:36 +0100, Jani Nikula
> > wrote:
> >
> >> @@ -116,6 +116,34 @@
> >> * #define GEN8_BAR_MMIO(0xb888)
> >> */
> >> +/**
> >> + * REG_BIT() - Prepare a u3
Quoting Thomas Gleixner (2019-02-28 10:09:26)
> On Thu, 28 Feb 2019, Chris Wilson wrote:
>
> > Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38)
> > > On 2019-02-12 17:28:57 [+0100], To linux-ker...@vger.kernel.org wrote:
> > > > The timer is initialized with TIMER_IRQSAFE flag. It does look
As our allocations are not device specific, we can move our slab caches
to a global scope.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 6 ---
drivers/gpu/drm/i915/i915_gem.c
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity lifetimes, but you can
also argue that activity
We currently use a worker queued from an rcu callback to determine when
a how grace period has elapsed while we remained idle. We use this idle
delay to infer that we will be idle for a while and this is a suitable
point at which we can trim our global memory caches.
Since we wrote that, this mech
On Thu, 28 Feb 2019, Michal Wajdeczko wrote:
> On Wed, 27 Feb 2019 18:02:38 +0100, Jani Nikula
> wrote:
>
>> @@ -108,9 +108,9 @@
>> * #define FOO(pipe) _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
>> * #define FOO_ENABLEREG_BIT(31)
>> * #define FOO_MODE_MASK
On Thu, 28 Feb 2019, Chris Wilson wrote:
> Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38)
> > On 2019-02-12 17:28:57 [+0100], To linux-ker...@vger.kernel.org wrote:
> > > The timer is initialized with TIMER_IRQSAFE flag. It does look like the
> > > timer callback requires this flag at all
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Make request allocation caches
global
URL : https://patchwork.freedesktop.org/series/57337/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dec6b371eb67 drm/i915: Make request allocation caches global
-:163: WA
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Make request allocation caches
global
URL : https://patchwork.freedesktop.org/series/57337/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make request allocation caches gl
On 26/02/2019 10:24, Chris Wilson wrote:
Having introduced per-context seqno, we now have a means to identity
progress across the system without feel of rollback as befell the
global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in
advance of submission safe in the knowledge that o
On Thu, 28 Feb 2019, Chris Wilson wrote:
> Quoting Thomas Gleixner (2019-02-28 10:09:26)
> > On Thu, 28 Feb 2019, Chris Wilson wrote:
> > > It may not be the best of api, but it's the only one available for the
> > > driver to use...
> >
> > The comment in the header files says clearly:
> >
> >
Adding intel-gfx and CI folks.
On Thu, Feb 28, 2019 at 9:22 AM Gerd Hoffmann wrote:
> Quick question on the Intel CI: How does it work? I've seen it sending
> mails. Does it report failures only, i.e. no news is good news? How
> long does it usually take to run the tests? Is waiting a day en
On Thu, Feb 28, 2019 at 11:52:39AM +0100, Daniel Vetter wrote:
> Adding intel-gfx and CI folks.
>
> On Thu, Feb 28, 2019 at 9:22 AM Gerd Hoffmann wrote:
> > Quick question on the Intel CI: How does it work? I've seen it sending
> > mails. Does it report failures only, i.e. no news is good news
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Make request allocation caches
global
URL : https://patchwork.freedesktop.org/series/57337/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5671 -> Patchwork_12326
=
On Thu, 28 Feb 2019 11:12:43 +0100, Chris Wilson
wrote:
But I think the central tenant is that we want to use the common naming
scheme so that we can trivially go from GENMASK to REG_GENMASK/GENMASK32
and that other people reading our code already know the language (plus
we want these to be p
Hi,
On 28-02-19 10:15, Heikki Krogerus wrote:
On Wed, Feb 27, 2019 at 04:45:32PM +0100, Hans de Goede wrote:
Hi,
On 27-02-19 12:16, Jani Nikula wrote:
On Wed, 27 Feb 2019, Heikki Krogerus wrote:
One thing that this series does not consider is the DP lane count
problem. The GPU drivers (i915
On Wed, Feb 27, 2019 at 03:04:07PM -0800, José Roberto de Souza wrote:
> Atomic state needs to be put even if the commit was successful.
>
> Fixes: dba14b27dd3c ("drm/i915: Reinitialize sink scrambling/TMDS clock ratio
> on HPD")
> Cc: Ville Syrjälä
> Cc: Lyude Paul
> Signed-off-by: José Robert
On Wed, Feb 27, 2019 at 03:04:08PM -0800, José Roberto de Souza wrote:
> drm_atomic_commit() call chain already takes care of adding
> connectors and planes, so lets no add then manually if not changing
> their states.
The specific callgraph would make review easier.
>
> Cc: Ville Syrjälä
> Cc:
On Thu, 28 Feb 2019 11:24:53 +0100, Jani Nikula
wrote:
On Thu, 28 Feb 2019, Michal Wajdeczko wrote:
On Wed, 27 Feb 2019 18:02:38 +0100, Jani Nikula
wrote:
@@ -108,9 +108,9 @@
* #define FOO(pipe) _MMIO_PIPE(pipe, _FOO_A,
_FOO_B)
* #define FOO_ENABLE
On Tue, Feb 26, 2019 at 10:17:10PM +0100, Daniel Vetter wrote:
> Hi Greg&Arnd
>
> topic/mei-hdcp-2019-02-26:
> mei-hdcp driver
>
> mei driver for the me hdcp client, for use by drm/i915.
>
> Including the following prep work:
> - whitelist hdcp client in mei bus
> - merge to include char-misc-ne
Part of the ongoing effort to remove the last vestiges of global_seqno.
The seqno may be gone, but the higher layers still have some assumptions
backed into them about the order of requests.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.
We can no longer assume execution ordering, and in particular we cannot
assume which context will execute last. One side-effect of this is that
we cannot determine if the kernel-context is resident on the GPU, so
remove the routines that claimed to do so.
Signed-off-by: Chris Wilson
---
drivers/
Currently we assume that we know the order in which requests run and so
can determine if we need to reissue a switch-to-kernel-context prior to
idling. That assumption does not hold for the future, so instead of
tracking which barriers have been used, simply determine if we have ever
switched away
In the next patch, we are introducing a broad virtual engine to encompass
multiple physical engines, losing the 1:1 nature of BIT(engine->id). To
reflect the broader set of engines implied by the virtual instance, lets
store the full bitmask.
v2: Use intel_engine_mask_t (s/ring_mask/engine_mask/)
We can reduce the switch-to-kernel-context selftest to operate as a loop
and so trivially test another state transition (that of idle->busy).
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_context.c | 80 ---
1 file changed, 35 insertions(+), 45 deletions(-)
When the system idles, we switch to the kernel context as a defensive
measure (no users are harmed if the kernel context is lost). Currently,
we issue a switch to kernel context and then come back later to see if
the kernel context is still current and the system is idle. However,
if we are no long
To facilitate the next patch to allow preemptible kernels not to incur
the wrath of hangcheck, we need to ensure that we can still suspend and
shutdown. That is we will not be able to rely on hangcheck to terminate
a blocking kernel and instead must manually do so ourselves. The
advantage is that w
We load a context (the kernel context) on both module load and resume in
order to initialise some logical state onto the GPU. We can use the same
routine for both operations, which will become more useful as we
refactor rc6/rps enabling.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Make request allocation caches
global
URL : https://patchwork.freedesktop.org/series/57337/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5671_full -> Patchwork_12326_full
===
On 26/02/2019 10:23, Chris Wilson wrote:
WAIT is occasionally suppressed by virtue of preempted requests being
promoted to NEWCLIENT if they have not all ready received that boost.
Make this consistent for all WAIT boosts that they are not allowed to
preempt executing contexts and are merely gra
== Series Details ==
Series: series starting with [1/7] drm/i915: Force GPU idle on suspend
URL : https://patchwork.freedesktop.org/series/57340/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d41d2721dd09 drm/i915: Force GPU idle on suspend
6bdef4e41a5f drm/i915/selftests: Impr
== Series Details ==
Series: series starting with [1/7] drm/i915: Force GPU idle on suspend
URL : https://patchwork.freedesktop.org/series/57340/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Force GPU idle on suspend
Okay!
Commit: drm/i915
== Series Details ==
Series: series starting with [1/7] drm/i915: Force GPU idle on suspend
URL : https://patchwork.freedesktop.org/series/57340/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5673 -> Patchwork_12327
Summary
On 26/02/2019 10:23, Chris Wilson wrote:
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing
There is no point in whitelisting a register that the user then cannot
write to, so check the register exists before merging such patches.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/intel_workarounds.c| 331 ++
1 file changed, 331 insertions(+)
diff --git a/drive
On 26/02/2019 10:24, Chris Wilson wrote:
If we resubmitting the active context, simply skip the submission as
we are
performing the submission from the interrupt handler has higher
From the tasklet? You mean wait for ctx complete and then
execlists_dequeue, instead of lite-restore?
Rega
There is no point in whitelisting a register that the user then cannot
write to, so check the register exists before merging such patches.
Signed-off-by: Chris Wilson
---
Check the writemask isn't 0!
---
.../drm/i915/selftests/intel_workarounds.c| 340 ++
1 file changed, 340
On Thu, Feb 28, 2019 at 01:03:14PM +0200, Arkadiusz Hiler wrote:
> On Thu, Feb 28, 2019 at 11:52:39AM +0100, Daniel Vetter wrote:
> > Adding intel-gfx and CI folks.
> >
> > On Thu, Feb 28, 2019 at 9:22 AM Gerd Hoffmann wrote:
> > > Quick question on the Intel CI: How does it work? I've seen it
There is no point in whitelisting a register that the user then cannot
write to, so check the register exists before merging such patches.
Signed-off-by: Chris Wilson
---
Check context creation error
---
.../drm/i915/selftests/intel_workarounds.c| 345 ++
1 file changed, 345
Bad EDID are a fact of life when dealing with random monitors. We only
spam the logs when debugging is enabled, but we only need to raise
notice and not set off the warning bells.
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
---
drivers/gpu/drm/drm_edid.c | 11 +--
1 file changed,
On Thu, 28 Feb 2019, Michal Wajdeczko wrote:
> On Thu, 28 Feb 2019 11:24:53 +0100, Jani Nikula
> wrote:
>
>> On Thu, 28 Feb 2019, Michal Wajdeczko wrote:
>>> On Wed, 27 Feb 2019 18:02:38 +0100, Jani Nikula
>>> wrote:
>>>
@@ -108,9 +108,9 @@
* #define FOO(pipe) _
On Thu, Feb 28, 2019 at 1:00 PM Greg KH wrote:
>
> On Tue, Feb 26, 2019 at 10:17:10PM +0100, Daniel Vetter wrote:
> > Hi Greg&Arnd
> >
> > topic/mei-hdcp-2019-02-26:
> > mei-hdcp driver
> >
> > mei driver for the me hdcp client, for use by drm/i915.
> >
> > Including the following prep work:
> > -
== Series Details ==
Series: drm/i915/selftests: Check that whitelisted registers are accessible
(rev2)
URL : https://patchwork.freedesktop.org/series/57342/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5673 -> Patchwork_12328
== Series Details ==
Series: drm/i915/selftests: Check that whitelisted registers are accessible
(rev3)
URL : https://patchwork.freedesktop.org/series/57342/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5673 -> Patchwork_12329
On Thu, Feb 28, 2019 at 01:42:33PM +, Chris Wilson wrote:
> Bad EDID are a fact of life when dealing with random monitors. We only
> spam the logs when debugging is enabled, but we only need to raise
> notice and not set off the warning bells.
>
> Signed-off-by: Chris Wilson
> Cc: Maarten Lan
From: Tvrtko Ursulin
Probably a leftover from test renames:
tests/Makefile.am:134: warning: variable 'pm_rc6_residency_LDADD' is defined
but no program or
tests/Makefile.am:134: library has 'pm_rc6_residency' as canonical name
(possible typo)
Signed-off-by: Tvrtko Ursulin
---
tests/Make
From: Tvrtko Ursulin
We do not bother explicitly unmapping memory on exit so no need to store
address and size in the workload step struct.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsi
From: Tvrtko Ursulin
Meson build does it so make the two symmetrical in this respect.
Signed-off-by: Tvrtko Ursulin
---
configure.ac | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure.ac b/configure.ac
index 4f55ea5d0f89..210e2c57df55 100644
--- a/configure.ac
+++ b/configure.ac
@
From: Tvrtko Ursulin
mmap(2) mandates size is page aligned so check this in our wrappers.
Signed-off-by: Tvrtko Ursulin
---
lib/i915/gem_mman.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
index 3cf9a6bbdb31..084dbb3b3678 100644
--- a/lib/i9
From: Tvrtko Ursulin
mmap(2) mandates size is page aligned.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
index 0a5abc08d8c2..57ceb983cf82 100644
--- a/benchmarks/
Quoting Tvrtko Ursulin (2019-02-28 14:18:24)
> From: Tvrtko Ursulin
>
> mmap(2) mandates size is page aligned so check this in our wrappers.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> lib/i915/gem_mman.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/lib/i915/gem_mman.c b/lib/i91
Quoting Tvrtko Ursulin (2019-02-28 14:18:25)
> From: Tvrtko Ursulin
>
> mmap(2) mandates size is page aligned.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> benchmarks/gem_wsim.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem
Quoting Tvrtko Ursulin (2019-02-28 14:18:26)
> From: Tvrtko Ursulin
>
> We do not bother explicitly unmapping memory on exit so no need to store
> address and size in the workload step struct.
If compiler happy, and I'm happy about leaving the mmap dangling for the
kernel to clean up,
Reviewed-
Quoting Tvrtko Ursulin (2019-02-28 14:18:27)
> From: Tvrtko Ursulin
>
> Meson build does it so make the two symmetrical in this respect.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> configure.ac | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 4f55ea
Quoting Tvrtko Ursulin (2019-02-28 14:18:28)
> From: Tvrtko Ursulin
>
> Probably a leftover from test renames:
>
> tests/Makefile.am:134: warning: variable 'pm_rc6_residency_LDADD' is
> defined but no program or
> tests/Makefile.am:134: library has 'pm_rc6_residency' as canonical name
> (p
On 28/02/2019 14:24, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-02-28 14:18:24)
From: Tvrtko Ursulin
mmap(2) mandates size is page aligned so check this in our wrappers.
Signed-off-by: Tvrtko Ursulin
---
lib/i915/gem_mman.c | 4
1 file changed, 4 insertions(+)
diff --git a/li
On 28/02/2019 14:25, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-02-28 14:18:25)
From: Tvrtko Ursulin
mmap(2) mandates size is page aligned.
Signed-off-by: Tvrtko Ursulin
---
benchmarks/gem_wsim.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/benchmarks/
On 28/02/2019 14:31, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-02-28 14:18:27)
From: Tvrtko Ursulin
Meson build does it so make the two symmetrical in this respect.
Signed-off-by: Tvrtko Ursulin
---
configure.ac | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure.ac b/
Quoting Tvrtko Ursulin (2019-02-28 14:41:23)
>
> On 28/02/2019 14:25, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-02-28 14:18:25)
> >> From: Tvrtko Ursulin
> >>
> >> mmap(2) mandates size is page aligned.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> benchmarks/gem_wsim.c | 7
Hi Hans,
On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:
> Hi,
>
> On 28-02-19 10:15, Heikki Krogerus wrote:
> > On Wed, Feb 27, 2019 at 04:45:32PM +0100, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 27-02-19 12:16, Jani Nikula wrote:
> > > > On Wed, 27 Feb 2019, Heikki Krogerus
On 28/02/2019 14:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-02-28 14:18:28)
From: Tvrtko Ursulin
Probably a leftover from test renames:
tests/Makefile.am:134: warning: variable 'pm_rc6_residency_LDADD' is defined
but no program or
tests/Makefile.am:134: library has 'pm_rc6_r
== Series Details ==
Series: drm: Slightly quieten bad EDID messages
URL : https://patchwork.freedesktop.org/series/57343/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5674 -> Patchwork_12330
Summary
---
**SUCCESS**
HI,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Gerd
> Hoffmann
> Sent: torstai 28. helmikuuta 2019 15.28
> To: Hiler, Arkadiusz
> Cc: Sarvela, Tomi P ; intel-gfx g...@lists.freedesktop.org>
> Subject: Re: [Intel-gfx] [PATCH v6
== Series Details ==
Series: drm/i915/selftests: Check that whitelisted registers are accessible
(rev3)
URL : https://patchwork.freedesktop.org/series/57342/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5673 -> Patchwork_12329
fi-kbl-guc's swap ran dry while running blt-vs-render-ctxN, which is
midly concerning but conceivable as we never checked there was enough
memory to run the test to begin with.
Each child needs to keep its own surface and possible a pair of logical
contexts (one for rcs and one for bcs) so check t
On Wed, 2019-02-27 at 23:03 +0200, Ville Syrjälä wrote:
> So instead of putting this logic into the EDID parser I guess we
> could just put it into the i915 fixed mode code. But then I suppose
> we should also fix EDID_QUIRK_FIRST_DETAILED_PREFERRED (assuming it
> exists for a good reason).
I don
We have an exported function for stopping the engine before
disabling a ringbuffer. Take it into use.
v2: use fw on empty check
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++
drivers/gpu/drm/i915/intel_ringbuffer.c
We use identical sequence of stopping ringbuffer on reset
handing and on ring initialization. Make a function
to handle both cases.
v2: intel_engine_stop_ring, cleaner stop_ring (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 18 +
Hardware cannot be in a middle of idle flow messaging
when we pull the plug from ringbuffer. Disable idle
messaging before we do so to avoid potential deadlock
on engine initialization and reset.
v2: INVALID_MMIO_REG, unconditional enable (Chris)
v3: comment (Chris), bspec reference
References: b
On Thu, Feb 28, 2019 at 02:32:38AM +0200, Souza, Jose wrote:
> [...]
> > > + * and then retrying the probe.
> > > + */
> > > + if (state == INTEL_HOTPLUG_NOCHANGE &&
> > > + connector->base.status != connector_status_connected &&
> > > + irq_received && intel_port_is_tc(dev_priv, encoder-
Mika Kuoppala writes:
> We have an exported function for stopping the engine before
> disabling a ringbuffer. Take it into use.
>
> v2: use fw on empty check
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> Reviewed-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++
We have an exported function for stopping the engine before
disabling a ringbuffer. Take it into use.
v2: use fw on empty check
v3: tail is tail
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 3 ++
drivers/gpu/drm/i915/in
Quoting Mika Kuoppala (2019-02-28 16:01:33)
> Hardware cannot be in a middle of idle flow messaging
> when we pull the plug from ringbuffer. Disable idle
> messaging before we do so to avoid potential deadlock
> on engine initialization and reset.
>
> v2: INVALID_MMIO_REG, unconditional enable (Ch
== Series Details ==
Series: series starting with [1/7] drm/i915: Force GPU idle on suspend
URL : https://patchwork.freedesktop.org/series/57340/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5673_full -> Patchwork_12327_full
===
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-02-28 16:01:33)
>> Hardware cannot be in a middle of idle flow messaging
>> when we pull the plug from ringbuffer. Disable idle
>> messaging before we do so to avoid potential deadlock
>> on engine initialization and reset.
>>
>> v2: INVALID_MMI
Quoting Mika Kuoppala (2019-02-28 16:14:11)
> We have an exported function for stopping the engine before
> disabling a ringbuffer. Take it into use.
>
> v2: use fw on empty check
> v3: tail is tail
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> Reviewed-by: Chris Wilson
> ---
> driver
On Wed, Feb 27, 2019 at 05:32:55PM -0800, José Roberto de Souza wrote:
> Forcing a specific CRTC to the eDP connector was causing the
> intel_psr_fastset_force() to mark mode_chaged in the wrong and
> disabled CRTC causing no update in the PSR state.
>
> Looks like our internal state track do not
On Wed, Feb 27, 2019 at 05:32:56PM -0800, José Roberto de Souza wrote:
> In any commit, intel_modeset_pipe_config() will initialilly clear
> and then recalculate most of the pipe states but it leave intel
> specific color features states in reset state.
>
> If after intel_pipe_config_compare() is
Quoting Mika Kuoppala (2019-02-28 16:01:32)
> We use identical sequence of stopping ringbuffer on reset
> handing and on ring initialization. Make a function
> to handle both cases.
>
> v2: intel_engine_stop_ring, cleaner stop_ring (Chris)
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
Rev
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-02-28 16:14:11)
>> We have an exported function for stopping the engine before
>> disabling a ringbuffer. Take it into use.
>>
>> v2: use fw on empty check
>> v3: tail is tail
>>
>> Cc: Chris Wilson
>> Signed-off-by: Mika Kuoppala
>> Reviewed
Hi Heikki,
On 28-02-19 15:47, Heikki Krogerus wrote:
Hi Hans,
On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:
Hi,
On 28-02-19 10:15, Heikki Krogerus wrote:
I've been thinking about this... Do we actually need to link the
correct drm_connector to the Type-C connector? Perha
On Wed, Feb 27, 2019 at 05:32:57PM -0800, José Roberto de Souza wrote:
> Other features like PSR2 also needs to be disabled while getting CRC
> so lets rename ips_force_disable to crc_enabled, drop all this checks
> for pipe A and HSW and BDW and make it generic and
> hsw_compute_ips_config() will
On Wed, Feb 27, 2019 at 05:32:58PM -0800, José Roberto de Souza wrote:
> When PSR2 is active aka after the number of frames programmed in
> PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
> interruptions causing IGT tests to fail due timeout.
>
> Oddly that don't happen when PSR1
Not exactly sure what's the aim here, but the canonical nil object has
id == 0, we don't use negative object ids for anything. Plus all
object_id are valided by the object_idr, there's nothing we need to do
on top of that ENOENT check a bit further down.
Spotted while typing exhaustive igt coverag
1 - 100 of 156 matches
Mail list logo
