If execlists's lite-restore is based on the common GEM context tag
rather than the per-intel_context LRCA, then a context switch between
two intel_contexts on the same engine derived from the same GEM context
will perform a lite-restore instead of a full context switch. We can
exploit this by poiso
On 2019-10-02 at 03:27:02 +, Patchwork wrote:
> == Series Details ==
>
> Series: DC3CO Support for TGL (rev14)
> URL : https://patchwork.freedesktop.org/series/64923/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6985_full -> Patchwork_14612_full
> ==
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix audio power up sequence for
gen10/11
URL : https://patchwork.freedesktop.org/series/67460/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6986_full -> Patchwork_14617_full
===
== Series Details ==
Series: drm/i915/selftests: Exercise potential false lite-restore (rev6)
URL : https://patchwork.freedesktop.org/series/67438/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
352a7d913600 drm/i915/selftests: Exercise potential false lite-restore
-:30: WARNING
== Series Details ==
Series: drm/i915/selftests: Exercise potential false lite-restore (rev6)
URL : https://patchwork.freedesktop.org/series/67438/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6986 -> Patchwork_14622
Summa
Hi Daniel,
once more a ping on this. Any more comments or can we get it comitted?
Thanks,
Christian.
Am 24.09.19 um 11:50 schrieb Christian König:
> Am 17.09.19 um 16:56 schrieb Daniel Vetter:
>> [SNIP]
+ /* When either the importer or the exporter
can't handl
If execlists's lite-restore is based on the common GEM context tag
rather than the per-intel_context LRCA, then a context switch between
two intel_contexts on the same engine derived from the same GEM context
will perform a lite-restore instead of a full context switch. We can
exploit this by poiso
== Series Details ==
Series: series starting with [1/2] drm/i915: Use a modparam to restrict exposed
engines (rev2)
URL : https://patchwork.freedesktop.org/series/67450/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6986_full -> Patchwork_14618_full
==
On 01/10/2019 18:49, Chris Wilson wrote:
Having decided to close the GTT mmap of userptr objects loophole in the
kernel, we need to adjust the test suite to avoid tripping over GTT
mmaps when required.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_userptr_blits.c | 32 ++
Quoting Tvrtko Ursulin (2019-10-02 09:42:01)
>
> On 01/10/2019 18:49, Chris Wilson wrote:
> > @@ -1225,7 +1247,7 @@ static void test_readonly_mmap(int i915)
> > original = g_compute_checksum_for_data(G_CHECKSUM_SHA1, pages, sz);
> >
> > ptr = __gem_mmap__gtt(i915, handle, sz, PROT_W
Having decided to close the GTT mmap of userptr objects loophole in the
kernel, we need to adjust the test suite to avoid tripping over GTT
mmaps when required.
v2: Refine read-only test to only skip checking GTT mmap interface.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem
== Series Details ==
Series: drm/i915/selftests: Exercise potential false lite-restore (rev7)
URL : https://patchwork.freedesktop.org/series/67438/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8ec84e229d3e drm/i915/selftests: Exercise potential false lite-restore
-:30: WARNING
On 01/10/2019 18:36, Chris Wilson wrote:
Quoting Ramalingam C (2019-10-01 18:26:24)
Read of FF_MODE2 register is broken at TGL A0. Hence verification of the
Wa_1604555607 associated to that register needs to be skipped.
Signed-off-by: Ramalingam C
cc: Tvrtko Ursulin
---
drivers/gpu/drm/i91
On 01/10/2019 18:35, Chris Wilson wrote:
Quoting Ramalingam C (2019-10-01 18:26:23)
From: Michel Thierry
Implement Wa_1604555607 (set the DS pairing timer to 128 cycles).
FF_MODE2 is part of the register state context, that's why it is
implemented here.
v2: Rebased on top of the WA refactori
On Tuesday, October 1, 2019 9:32:32 PM CEST Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Conclude load -> probe naming convention switch
> URL : https://patchwork.freedesktop.org/series/67454/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6986 -> Pat
On Tuesday, October 1, 2019 9:08:48 PM CEST Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Conclude load -> probe naming convention switch
> URL : https://patchwork.freedesktop.org/series/67454/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> f23ba0cec2
== Series Details ==
Series: drm/i915/selftests: Exercise potential false lite-restore (rev7)
URL : https://patchwork.freedesktop.org/series/67438/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6986 -> Patchwork_14623
Summa
On 02/10/2019 09:50, Chris Wilson wrote:
Having decided to close the GTT mmap of userptr objects loophole in the
kernel, we need to adjust the test suite to avoid tripping over GTT
mmaps when required.
v2: Refine read-only test to only skip checking GTT mmap interface.
Signed-off-by: Chris Wil
== Series Details ==
Series: series starting with [1/2] drm/i915/tgl: Implement Wa_1604555607
URL : https://patchwork.freedesktop.org/series/67461/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6986_full -> Patchwork_14619_full
=
Quoting Kai Vehmanen (2019-10-01 17:35:54)
> On gen10/11 platforms, driver must set the enable bit of AUD_PIN_BUF_CTL
> as part of audio power up sequence.
>
> Failing to do this resulted in errors during display audio codec probe,
> and failures during resume from suspend.
>
> Bugzilla: https://
On Tue, 01 Oct 2019, Jani Nikula wrote:
> While the main goal here is to abstract recurring patterns, and slightly
> clean up the code base by not open coding the ternary operators, there
> are also some space savings to be had via better string constant
> pooling.
Make that
"""
While the main g
On 2019-10-02 at 09:54:12 +0100, Tvrtko Ursulin wrote:
>
> On 01/10/2019 18:36, Chris Wilson wrote:
> > Quoting Ramalingam C (2019-10-01 18:26:24)
> > > Read of FF_MODE2 register is broken at TGL A0. Hence verification of the
> > > Wa_1604555607 associated to that register needs to be skipped.
> >
== Series Details ==
Series: drm/i915/mg: Use tc_port instead of port parameter to MG registers
URL : https://patchwork.freedesktop.org/series/67467/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6986_full -> Patchwork_14620_full
===
Hey,
On Wed, 2 Oct 2019, Chris Wilson wrote:
> > + if (INTEL_GEN(dev_priv) == 11 || INTEL_GEN(dev_priv) == 10)
> > + I915_WRITE(AUD_PIN_BUF_CTL,
> > + (I915_READ(AUD_PIN_BUF_CTL) |
> > + AUD_PIN
On 02/10/2019 12.11, Jani Nikula wrote:
> On Tue, 01 Oct 2019, Jani Nikula wrote:
>> While the main goal here is to abstract recurring patterns, and slightly
>> clean up the code base by not open coding the ternary operators, there
>> are also some space savings to be had via better string constan
With the introduction of ctx->engines[] we allow multiple logical
contexts to be used on the same engine (e.g. with virtual engines).
According to bspec, aach logical context requires a unique tag in order
for context-switching to occur correctly between them. [Simple
experiments show that it is no
As our global unpark/park keep track of the number of active users, we
can simply move the accounting from the GEM layer to the base GT layer.
It was placed originally inside GEM to benefit from the 100ms extra
delay on idleness, but that has been eliminated and now there is no
substantive differen
The premise here is to simply avoiding having to acquire the vm->mutex
inside vma create/destroy to update the vm->unbound_lists, to avoid some
nasty lock recursions later.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 2 +-
drivers/g
Having a struct_mutex around the read of a BIOS blob serves no purpose.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers
It appears we cannot consistently hit our self-imposed QoS target of 2s
for performing the reset (my theory is that is some RCU scheduling
quirk), so relax the assertion to a measly 10s.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105957
Signed-off-by: Chris Wilson
---
tests/i915/gem_
struct_mutex provides no serialisation of the registers and data
structures being saved and restored across suspend/resume. It is
completely superfluous here.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_suspend.c | 8
1 file changed, 8 deletion
On completion of a banned context, scrub the context image so that we do
not replay the active payload. The intent is that we skip banned
payloads on request submission so that the timeline advancement
continues on in the background. However, if we are returning to a
preempted request, i915_request
Forgo the struct_mutex serialisation for i915_active, and interpose its
own mutex handling for active/retire.
This is a multi-layered sleight-of-hand. First, we had to ensure that no
active/retire callbacks accidentally inverted the mutex ordering rules,
nor assumed that they were themselves seria
Nothing inside the idle worker now requires struct_mutex, so we can
remove the indirection of using our own worker.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 28 ++-
.../drm/i915/gem/selftests/i915_gem_mman.c|
wait_for_timelines is essentially the same loop as retiring requests
(with an extra timeout), so merge the two into one routine.
v2: i915_retire_requests_timeout and keep VT'd w/a as !interruptible
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_mm
The ulterior motive to switching the booleans over to bitops is to
allow use of the allocated flag as a bitlock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 36 +++
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 6 ++--
drivers/gpu/drm/i915/g
Normally, we rely on our hangcheck to prevent persistent batches from
hogging the GPU. However, if the user disables hangcheck, this mechanism
breaks down. Despite our insistence that this is unsafe, the users are
equally insistent that they want to use endless batches and will disable
the hangchec
Replace sampling the engine state every so often with a periodic
heartbeat request to measure the health of an engine. This is coupled
with the forced-preemption to allow long running requests to survive so
long as they do not block other users.
The heartbeat interval can be adjusted per-engine us
Requests are run from the gt and are tided into the gt runtime power
management, so pull the runtime request management under gt/
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4 +-
drivers/gpu/drm/i915/ge
Since we cannot allocate underneath the vm->mutex (it is used in the
direct-reclaim paths), we need to shift the allocations off into a
mutexless worker with fence recursion prevention. To know when we need
this protection, we mark up the address spaces that do allocate before
insertion. In the fut
If execlists's lite-restore is based on the common GEM context tag
rather than the per-intel_context LRCA, then a context switch between
two intel_contexts on the same engine derived from the same GEM context
will perform a lite-restore instead of a full context switch. We can
exploit this by poiso
Sometimes we want to emit a terminator request, a request that flushes
the pipeline and allows no request to come after it. This can be used
for a "preempt-to-idle" to ensure that upon processing the
context-switch to that request, all other active contexts have been
flushed.
Signed-off-by: Chris
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 14 +
.../gpu/drm/i915/gt/intel_engine_heartbeat.h | 1 +
Make dma_fence_enable_sw_signaling() behave like its
dma_fence_add_callback() and dma_fence_default_wait() counterparts and
perform the test to enable signaling under the fence->lock, along with
the action to do so. This ensure that should an implementation be trying
to flush the cb_list (by signal
Now that we now longer need to guarantee that the active callback is
under the struct_mutex, we can lift it out of the i915_gem_park() and
into the engine parking itself.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 19 -
The overlay uses the modeset mutex to control itself and only required
the struct_mutex for requests, which is now obsolete.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +--
drivers/gpu/drm/i915/display/intel_overlay.c | 13 -
If the preempted context takes too long to relinquish control, e.g. it
is stuck inside a shader with arbitration disabled, evict that context
with an engine reset. This ensures that preemptions are reasonably
responsive, providing a tighter QoS for the more important context at
the cost of flagging
Keep track of the GEM contexts underneath i915->gem.contexts and assign
them their own lock for the purposes of list management.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 155 +++---
drivers/gpu/drm/i915/gem/i915_gem_context.h
Now that we can retire without taking struct_mutex, we can do so to
handle shrinking the mmap-offset space after an allocation failure.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 17 +
1 file changed, 5 inserti
It protects nothing being accessed for the intel_framebuffer, so it's
own locking had better be sufficient.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.
== Series Details ==
Series: DC3CO Support for TGL (rev15)
URL : https://patchwork.freedesktop.org/series/64923/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6987 -> Patchwork_14624
Summary
---
**SUCCESS**
No reg
As we need to use a mutex to serialise i915_active activation
(because we want to allow the callback to sleep), we need to push the
i915_active.retire into a worker callback in case we get need to retire
from an atomic context.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
.../gpu/d
We no longer need to placate lockdep by holding struct_mutex for our
initialisation, so don't.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 --
drivers/gpu/drm/i915/i915_gem.c | 9 -
drivers/gpu/drm/i91
We don't need to hold struct_mutex now for retiring requests, so drop it
from i915_retire_requests() and i915_gem_wait_for_idle(), finally
removing I915_WAIT_LOCKED for good.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 7 +-
driv
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure. Later
We no longer need struct_mutex to serialise request emission, so remove
it from the gt selftests.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 15 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 4 -
.../drm/i915/gem/selftests
There's very little variation in non-privileged registers for Tigerlake,
so we can mostly inherit the set from gen11. There is no whitelist at
present, so we do not need to add any special registers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111599
Signed-off-by: Chris Wilson
---
te
On Wed, Oct 02, 2019 at 12:26:48PM +0100, Chris Wilson wrote:
> There's very little variation in non-privileged registers for Tigerlake,
> so we can mostly inherit the set from gen11. There is no whitelist at
> present, so we do not need to add any special registers.
>
> Bugzilla: https://bugs.fre
Slightly more complicated conversion than the earlier mass conversion as
deep() open-codes the execbuf loop, but still pretty simple replacement
of the plug object with the in-fence.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111646
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
On Tue, Oct 01, 2019 at 07:35:54PM +0300, Kai Vehmanen wrote:
> On gen10/11 platforms, driver must set the enable bit of AUD_PIN_BUF_CTL
> as part of audio power up sequence.
>
> Failing to do this resulted in errors during display audio codec probe,
> and failures during resume from suspend.
Goo
For selftests, we desire repeatability and so prefer using a prng with
known seed over true randomness. Extract random_offset() as a selftest
utility that can take the prng state.
Suggested-by: Matthew Auld
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_ge
We repeat obj->ops->flags in our object checks, so pull that into its
own little helper for clarity.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
If we process DROP_RESET_ACTIVE and cancel all outstanding requests by
forcing a GPU reset on a hardware with reset capabilities disabled or
not supported, we certainly end up with a terminally wedged GPU,
impossible to recover. That's probably not what we want.
Before setting the GPU wedged, ver
On 02/10/2019 13:24, Chris Wilson wrote:
For selftests, we desire repeatability and so prefer using a prng with
known seed over true randomness. Extract random_offset() as a selftest
utility that can take the prng state.
Suggested-by: Matthew Auld
Signed-off-by: Chris Wilson
Cc: Matthew Auld
On 02/10/2019 13:30, Chris Wilson wrote:
We repeat obj->ops->flags in our object checks, so pull that into its
own little helper for clarity.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-g
== Series Details ==
Series: i915/gem_exec_schedule: Replace vgem fence with sync_file
URL : https://patchwork.freedesktop.org/series/67486/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6988 -> IGTPW_3528
Summary
---
Rename the function per Ville's suggestion. No functional changes.
Cc: Ville Syrjälä
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
drivers/gpu/drm/i915/display/intel_vga.c | 2 +-
drivers/gpu/drm/i915/display/int
Split out code related to vga switcheroo register/unregister and state
handling from i915_drv.c into new i915_switcheroo.[ch] files.
It's a bit difficult to draw the line how much to move to the new file
from i915_drv.c, but it seemed to me keeping i915_suspend_switcheroo()
and i915_resume_switche
Pair the gmbus setup and teardown in the same layer. This also fixes the
double gmbus teardown on the i915_driver_modeset_probe() error path.
Move the gmbus setup a bit later in the sequence to make the follow-up
refactoring easier, and to pinpoint any unexpected consequences of this
change right
Move vga switcheroo and dsm handler register later in
i915_driver_register(), and unregister in i915_driver_unregister(). The
dsm handler unregister is a nop, and is only added for completeness.
My unsubstantiated suspicion is that the vga switcheroo state change
would not work as early as we regi
== Series Details ==
Series: series starting with [01/30] drm/i915/selftests: Exercise potential
false lite-restore
URL : https://patchwork.freedesktop.org/series/67483/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
099f6ae3c72d drm/i915/selftests: Exercise potential false lit
== Series Details ==
Series: series starting with [01/30] drm/i915/selftests: Exercise potential
false lite-restore
URL : https://patchwork.freedesktop.org/series/67483/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/selftests: Exercise poten
== Series Details ==
Series: series starting with [01/30] drm/i915/selftests: Exercise potential
false lite-restore
URL : https://patchwork.freedesktop.org/series/67483/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6988 -> Patchwork_14625
Quoting Patchwork (2019-10-02 14:46:05)
> == Series Details ==
>
> Series: series starting with [01/30] drm/i915/selftests: Exercise potential
> false lite-restore
> URL : https://patchwork.freedesktop.org/series/67483/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_
== Series Details ==
Series: drm/i915/selftests: Extract random_offset() for use with a prng
URL : https://patchwork.freedesktop.org/series/67489/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
62126230edd7 drm/i915/selftests: Extract random_offset() for use with a prng
-:37: CH
> -Original Message-
> From: Chris Wilson
> Sent: Wednesday, October 2, 2019 4:20 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Joonas Lahtinen
> ; Winiarski, Michal
> ; Bloomfield, Jon
> Subject: [PATCH 20/30] drm/i915: Cancel non-persistent contexts on close
>
> Norma
On Tue, 01 Oct 2019, Ville Syrjälä wrote:
> On Tue, Oct 01, 2019 at 06:25:06PM +0300, Jani Nikula wrote:
>> Split out the code related to vga client and vgaarb all over the place
>> into new intel_vga.[ch]. No functional changes.
>>
>> Cc: Ville Syrjälä
>> Cc: Chris Wilson
>> Signed-off-by: Jan
> -Original Message-
> From: Chris Wilson
> Sent: Wednesday, October 2, 2019 4:20 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Joonas Lahtinen
> ; Ursulin, Tvrtko ;
> Bloomfield, Jon
> Subject: [PATCH 21/30] drm/i915: Replace hangcheck by heartbeats
>
> Replace sampling
If execlists's lite-restore is based on the common GEM context tag
rather than the per-intel_context LRCA, then a context switch between
two intel_contexts on the same engine derived from the same GEM context
will perform a lite-restore instead of a full context switch. We can
exploit this by poiso
Quoting Bloomfield, Jon (2019-10-02 14:52:32)
>
>
> > -Original Message-
> > From: Chris Wilson
> > Sent: Wednesday, October 2, 2019 4:20 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson ; Joonas Lahtinen
> > ; Winiarski, Michal
> > ; Bloomfield, Jon
> > Subject: [PATCH 2
For historical reasons, the function drm_wait_vblank_ioctl always return
-EINVAL if something gets wrong. This scenario limits the flexibility
for the userspace to make detailed verification of any problem and take
some action. In particular, the validation of “if (!dev->irq_enabled)”
in the drm_wa
The Thunderbolt PLL divider values on TGL differ from the ICL ones,
update the PLL parameter calculation function accordingly.
Bspec: 49204
Cc: Jose Souza
Cc: Clinton A Taylor
Cc: Lucas De Marchi
Cc: Mika Westerberg
Tested-by: Mika Westerberg
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i9
On Tue, 24 Sep 2019, Jani Nikula wrote:
> drm/print: move drm_debug variable to drm_print.[ch]
> drm/print: add drm_debug_enabled()
> drm/etnaviv: use drm_debug_enabled() to check for debug categories
> drm/i2c/sil164: use drm_debug_enabled() to check for debug categories
> drm/msm: use
== Series Details ==
Series: drm/i915/selftests: Extract random_offset() for use with a prng
URL : https://patchwork.freedesktop.org/series/67489/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6988 -> Patchwork_14626
Summar
Quoting Bloomfield, Jon (2019-10-02 14:52:32)
>
>
> > -Original Message-
> > From: Chris Wilson
> > Sent: Wednesday, October 2, 2019 4:20 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson ; Joonas Lahtinen
> > ; Winiarski, Michal
> > ; Bloomfield, Jon
> > Subject: [PATCH 2
Normally, we rely on our hangcheck to prevent persistent batches from
hogging the GPU. However, if the user disables hangcheck, this mechanism
breaks down. Despite our insistence that this is unsafe, the users are
equally insistent that they want to use endless batches and will disable
the hangchec
Quoting Bloomfield, Jon (2019-10-02 14:55:32)
> > -Original Message-
> > From: Chris Wilson
> > Sent: Wednesday, October 2, 2019 4:20 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson ; Joonas Lahtinen
> > ; Ursulin, Tvrtko
> > ;
> > Bloomfield, Jon
> > Subject: [PATCH 21/3
On Tue, 01 Oct 2019, Kai Vehmanen wrote:
> On gen10/11 platforms, driver must set the enable bit of AUD_PIN_BUF_CTL
> as part of audio power up sequence.
>
> Failing to do this resulted in errors during display audio codec probe,
> and failures during resume from suspend.
>
> Bugzilla: https://bug
> -Original Message-
> From: Chris Wilson
> Sent: Wednesday, October 2, 2019 7:23 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Joonas Lahtinen
> ; Winiarski, Michal
> ; Bloomfield, Jon
> Subject: [PATCH v2] drm/i915: Cancel non-persistent contexts on close
>
> Normally,
> -Original Message-
> From: Chris Wilson
> Sent: Wednesday, October 2, 2019 7:24 AM
> To: Bloomfield, Jon ; intel-
> g...@lists.freedesktop.org
> Cc: Joonas Lahtinen ; Winiarski, Michal
>
> Subject: RE: [PATCH 20/30] drm/i915: Cancel non-persistent contexts on close
>
> Quoting Bloomfie
Add aux_busy_last_status to intel_dp. Don't bother with initializing to
all ones; the only difference is potentially missing logging for one
error case if the readout is all zeros.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/displ
On Wed, Oct 02, 2019 at 05:41:38PM +0300, Jani Nikula wrote:
> Add aux_busy_last_status to intel_dp. Don't bother with initializing to
> all ones; the only difference is potentially missing logging for one
> error case if the readout is all zeros.
>
> Signed-off-by: Jani Nikula a
Reviewed-by: Vil
Unify on current common usage to allow repurposing drm_dbg() later. Fix
newlines while at it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/dr
Unify on current common usage to allow repurposing drm_err() later. Fix
newlines while at it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/dr
On Wed, Oct 02, 2019 at 05:54:04PM +0300, Jani Nikula wrote:
> Unify on current common usage to allow repurposing drm_err() later. Fix
> newlines while at it.
>
> Signed-off-by: Jani Nikula
Series is
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8
On Wed, Oct 02, 2019 at 04:17:57PM +0300, Jani Nikula wrote:
> Rename the function per Ville's suggestion. No functional changes.
>
> Cc: Ville Syrjälä
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display_po
On Wed, Oct 02, 2019 at 04:17:58PM +0300, Jani Nikula wrote:
> Split out code related to vga switcheroo register/unregister and state
> handling from i915_drv.c into new i915_switcheroo.[ch] files.
>
> It's a bit difficult to draw the line how much to move to the new file
> from i915_drv.c, but it
On Wed, Oct 02, 2019 at 04:18:00PM +0300, Jani Nikula wrote:
> Pair the gmbus setup and teardown in the same layer. This also fixes the
> double gmbus teardown on the i915_driver_modeset_probe() error path.
>
> Move the gmbus setup a bit later in the sequence to make the follow-up
> refactoring ea
On 02/10/2019 12:19, Chris Wilson wrote:
It appears we cannot consistently hit our self-imposed QoS target of 2s
for performing the reset (my theory is that is some RCU scheduling
quirk), so relax the assertion to a measly 10s.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105957
Signe
On 02/10/2019 13:48, Janusz Krzysztofik wrote:
If we process DROP_RESET_ACTIVE and cancel all outstanding requests by
forcing a GPU reset on a hardware with reset capabilities disabled or
not supported, we certainly end up with a terminally wedged GPU,
impossible to recover. That's probably not
1 - 100 of 162 matches
Mail list logo
