On Fri, 31 Jul 2020 at 02:26, Joonas Lahtinen
wrote:
>
> Hi Dave & Daniel,
>
> (Covering for Jani here for drm-intel-next-fixes)
>
> 5 new commits over drm-intel-next here.
>
> Fix for KASAN detected race condition and linux-next scheduler
> WARNs. Patch to avoid IRQ spinlock and Cc: stable PMU re
On Thu, Aug 06, 2020 at 03:45:29PM +0100, Chris Wilson wrote:
> Unknown, so future, gen are marked as -1 which we want to treat as -1u
> so that always pass >= gen checks.
Do we really want to enable the tests when platform is not fully
enabled in IGT?
--
Zbigniew
>
> Closes: https://gitlab.fre
On Mon, Aug 10, 2020 at 10:09:46AM +0200, Zbigniew Kempczyński wrote:
> On Thu, Aug 06, 2020 at 03:45:29PM +0100, Chris Wilson wrote:
> > Unknown, so future, gen are marked as -1 which we want to treat as -1u
> > so that always pass >= gen checks.
>
> Do we really want to enable the tests when pla
Quoting Petri Latvala (2020-08-10 09:22:42)
> On Mon, Aug 10, 2020 at 10:09:46AM +0200, Zbigniew Kempczyński wrote:
> > On Thu, Aug 06, 2020 at 03:45:29PM +0100, Chris Wilson wrote:
> > > Unknown, so future, gen are marked as -1 which we want to treat as -1u
> > > so that always pass >= gen checks.
If we manage to hit the intel_gt_set_wedged_on_fini() while active, i.e.
module unload during a stress test, we may cancel the requests but not
clean up. This leads to a slow module unload as we wait for something or
other to trigger the retirement flushing. Instead if we explicitly
cancel then cle
Flush all the pending requests from the mock engine when they are
cancelled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/mock_engine.c | 29 +++
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
b/drivers/gpu
After making the requests on an engine as cancelled upon wedging, send
any signals for their completions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/d
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests
URL : https://patchwork.freedesktop.org/series/80459/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
On Fri, 2020-08-07 at 11:19 +0200, Janusz Krzysztofik wrote:
> Clean up the test code and unblock unbind variants.
From the CI report it looks for me like driver (hot)unbind-rebind
operations affect hardware and the driver doesn't handle this
correctly. Moreover, the test doesn't currently detect
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests
URL : https://patchwork.freedesktop.org/series/80459/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8862 -> Patchwork_18329
Summ
Quoting Tvrtko Ursulin (2020-08-06 10:21:38)
>
> On 05/08/2020 17:22, Thomas Hellström (Intel) wrote:
> > Hi, Chris,
> >
> >
> > On 8/5/20 2:21 PM, Chris Wilson wrote:
> >> Long story short, we need to manage evictions using dma_resv & dma_fence
> >> tracking. The backing storage will then be ma
From: Colin Ian King
There is a spelling mistake in a drm_err message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c
b/drivers/gpu/drm/i915/dis
-Original Message-
From: Chris Wilson
Sent: Friday, August 7, 2020 5:30 PM
To: Singh, Gaurav K ; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] i915/gem: Force HW tracking to exit PSR
Quoting Gaurav K Singh (2020-08-07 12:56:33)
> Instead of calling i915_gem_object_i
This reverts commit 964a9b0f611ee ("drm/i915/gem: Use chained reloc batches")
and commit 0e97fbb080553 ("drm/i915/gem: Use a single chained reloc batches
for a single execbuf").
When adding ww locking to execbuf, it's hard enough to deal with a
single BO that is part of relocation execution. Chain
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.
With this, we have a proper working slowpath again, which
will allow us to do fault
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
With the WW locking, we will drop all references only at the
end, so refcounting can be removed.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 124 +++---
1 file changed, 51 insertion
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+),
As soon as we install fences, we should stop allocating memory
in order to prevent any potential deadlocks.
This is required later on, when we start adding support for
dma-fence annotations, and also required for userptr.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_ex
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Ensure that execbuf selftests keep passing by using ww handling.
Changes since v2:
- Fix i915_gem_context finally.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_g
First start with a few reverts, to get to a good starting base for this
series:
- Async gpu relocations are not the way to go, for new platforms we will
disable gpu relocations altogether.
- We also need the relocation slowpath (EFAULT handling) back.
- The eb_vma no longer needs to be refcounted
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten La
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b23368529a40..548ed9fb427d 100644
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get call
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/
This reverts commit 9e0f9464e2ab36b864359a59b0e9058fdef0ce47,
and related commit 7ac2d2536dfa7 ("drm/i915/gem: Delete unused code").
Async GPU relocations are not the path forward, we want to remove
GPU accelerated relocation support eventually when userspace is fixed
to use VM_BIND, and this is t
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This fin
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: M
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insert
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
Rev
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
Signed-off-by: Maarten Lankhorst
---
drivers/g
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_
== Series Details ==
Series: drm/i915/vlv_dsi_pll: fix spelling mistake "Cant" -> "Can't"
URL : https://patchwork.freedesktop.org/series/80463/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8862 -> Patchwork_18330
Summary
-
== Series Details ==
Series: drm/i915: Correct the locking hierarchy in gem.
URL : https://patchwork.freedesktop.org/series/80465/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3f559a19757d Revert "drm/i915/gem: Async GPU relocations only"
-:121: WARNING:MEMORY_BARRIER: memory
== Series Details ==
Series: drm/i915: Correct the locking hierarchy in gem.
URL : https://patchwork.freedesktop.org/series/80465/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: Correct the locking hierarchy in gem.
URL : https://patchwork.freedesktop.org/series/80465/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8862 -> Patchwork_18331
Summary
---
**F
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests
URL : https://patchwork.freedesktop.org/series/80459/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8862_full -> Patchwork_18329_full
This patch probably needs a description, typing somethign here since it was
originally my patch:
With bigjoiner, there will be 2 pipes driving 2 halfs of 1 transcoder,
because of this, we need a pipe_mode for various calculations, including
for example watermarks, plane clipping, etc.
The transco
Op 16-07-2020 om 00:42 schreef Manasi Navare:
> From: Maarten Lankhorst
>
> Small changes to intel_dp_mode_valid(), allow listing modes that
> can only be supported in the bigjoiner configuration, which is
> not supported yet.
>
> eDP does not support bigjoiner, so do not expose bigjoiner only
> m
Don't assume the kernel will emit a semaphore to synchronise between two
engine, and emit the semaphore ourselves for the basis of our
measurements. The purpose of the test is to try and ascertain the
accuracy of the two sampling methods, semaphore busyness uses register
polling, whereas the engine
Op 16-07-2020 om 21:27 schreef Manasi Navare:
> On Wed, Jul 15, 2020 at 03:42:17PM -0700, Manasi Navare wrote:
>> From: Maarten Lankhorst
>>
>> Make vdsc work when no output is enabled. The big joiner needs VDSC
>> on the slave, so enable it and set the appropriate bits.
>> Also update timestampin
Op 16-07-2020 om 00:42 schreef Manasi Navare:
> From: Maarten Lankhorst
>
> Dump debugfs and planar links as well, this will make it easier to debug
> when things go wrong.
>
> v4:
> * Rebase
> Changes since v1:
> - Report planar slaves as such, now that we have the plane_state switch.
> Changes s
Op 10-08-2020 om 12:30 schreef Maarten Lankhorst:
> As soon as we install fences, we should stop allocating memory
> in order to prevent any potential deadlocks.
>
> This is required later on, when we start adding support for
> dma-fence annotations, and also required for userptr.
This patch causes
On Mon, Aug 10, 2020 at 01:25:40PM +0200, Christian König wrote:
> Am 09.08.20 um 08:17 schrieb Lukas Bulwahn:
> > With commit 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are
> > a bad idea"), document generation warns:
> >
> >Documentation/driver-api/dma-buf.rst:182: \
> >W
== Series Details ==
Series: drm/i915/vlv_dsi_pll: fix spelling mistake "Cant" -> "Can't"
URL : https://patchwork.freedesktop.org/series/80463/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8862_full -> Patchwork_18330_full
Am 09.08.20 um 08:17 schrieb Lukas Bulwahn:
With commit 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are
a bad idea"), document generation warns:
Documentation/driver-api/dma-buf.rst:182: \
WARNING: Title underline too short.
Repair length of title underline to remove warnin
---
drivers/gpu/drm/i915/dummy.c | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/i915/dummy.c
diff --git a/drivers/gpu/drm/i915/dummy.c b/drivers/gpu/drm/i915/dummy.c
new file mode 100644
index ..e69de29bb2d1
--
2.28.0
___
From: Abhishek Kumar
For NV12 display sub plane is also configured and drivers internally
create plane atomic state. Driver copies all of the param of main
plane atomic state to sub planer atomic state but in sub plane
atomic state crtc is not added ,so when drm atomic state is configured
for com
Op 10-08-2020 om 17:16 schreef Uma Shankar:
> From: Abhishek Kumar
>
> For NV12 display sub plane is also configured and drivers internally
> create plane atomic state. Driver copies all of the param of main
> plane atomic state to sub planer atomic state but in sub plane
> atomic state crtc is no
== Series Details ==
Series: drm/i915/display: Fix NV12 sub plane atomic state
URL : https://patchwork.freedesktop.org/series/80474/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1cf8e8b47de4 drm/i915/display: Fix NV12 sub plane atomic state
-:14: ERROR:GERRIT_CHANGE_ID: Remove
== Series Details ==
Series: drm/i915/display: Fix NV12 sub plane atomic state
URL : https://patchwork.freedesktop.org/series/80474/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
__
On Mon, 2020-07-06 at 16:43 -0700, José Roberto de Souza wrote:
> All GEN12 platforms supports PSR2 selective fetch but not all GEN12
> platforms supports PSR2 hardware tracking(aka RKL).
>
> This feature consists in software programming registers with the
> damaged area of each plane this way har
On Mon, 2020-07-06 at 16:43 -0700, José Roberto de Souza wrote:
> From the 3 WAs for PSR2 man track/selective fetch this is only one
> needed when doing single full frames at every flip.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 19 ++
> -Original Message-
> From: Maarten Lankhorst
> Sent: Monday, August 10, 2020 8:17 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Cc: Zuo, Alex ; Kumar, Abhishek4
> ; sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/i915/display: Fix NV12 sub plane atomic state
>
> Op 10-0
Trying to ensure that patchwork no longer sees the commit this is replied to.
---
drivers/gpu/drm/i915/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index bda4c0e408f8..f6f3fc651086 100644
--- a/drivers/gpu/drm/i915/Makef
== Series Details ==
Series: drm/i915/display: Fix NV12 sub plane atomic state
URL : https://patchwork.freedesktop.org/series/80474/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8864 -> Patchwork_18332
Summary
---
*
We assume that both timestamps are driven off the same clock [reported
to userspace as I915_PARAM_CS_TIMESTAMP_FREQUENCY]. Verify that this is
so by reading the timestamp registers around a busywait (on an otherwise
engine so there should be no preemptions).
Signed-off-by: Chris Wilson
---
drive
== Series Details ==
Series: drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock
URL : https://patchwork.freedesktop.org/series/80475/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
89b5186bbf39 drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP shar
== Series Details ==
Series: drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock
URL : https://patchwork.freedesktop.org/series/80475/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separ
== Series Details ==
Series: drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock
URL : https://patchwork.freedesktop.org/series/80475/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8864 -> Patchwork_18333
===
On Sat, 2020-08-08 at 02:15 +, Patchwork wrote:
> Patch Details
> Series: series starting with [CI,1/2] drm/i915/tgl: Set subplatforms
> URL: https://patchwork.freedesktop.org/series/80404/
> State:failure
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_1832
All GEN12 platforms supports PSR2 selective fetch but not all GEN12
platforms supports PSR2 hardware tracking(aka RKL).
This feature consists in software programming registers with the
damaged area of each plane this way hardware will only fetch from
memory those areas and sent the PSR2 selective
From the 3 WAs for PSR2 man track/selective fetch this is only one
needed when doing single full frames at every flip.
Reviewed-by: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 19 +--
drivers/gpu/drm/i915/i915_reg.h
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fi
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2
selective fetch
URL : https://patchwork.freedesktop.org/series/80478/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2802a6d0b15e drm/i915: Initial implementation of PSR2 selecti
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2
selective fetch
URL : https://patchwork.freedesktop.org/series/80478/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't b
Userspace may still create GEM dumb buffers even on platforms with
disabled or non-existent display. When creating dumb buffers we try to
check the max fb stride for the platform by looking at the first pipe on
the platform. We previously fixed a crash related to accessing the
non-existent PIPE_A
== Series Details ==
Series: drm/i915/display: Fix NV12 sub plane atomic state
URL : https://patchwork.freedesktop.org/series/80474/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8864_full -> Patchwork_18332_full
Summary
--
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2
selective fetch
URL : https://patchwork.freedesktop.org/series/80478/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8865 -> Patchwork_18334
== Series Details ==
Series: drm/i915: Don't try to check max stride for disabled/non-existent
display
URL : https://patchwork.freedesktop.org/series/80479/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked sep
== Series Details ==
Series: drm/i915: Don't try to check max stride for disabled/non-existent
display
URL : https://patchwork.freedesktop.org/series/80479/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8866 -> Patchwork_18335
=
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2
selective fetch
URL : https://patchwork.freedesktop.org/series/80478/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8865_full -> Patchwork_18334_full
==
Quoting Matt Roper (2020-08-10 19:08:51)
> Userspace may still create GEM dumb buffers even on platforms with
> disabled or non-existent display. When creating dumb buffers we try to
> check the max fb stride for the platform by looking at the first pipe on
> the platform. We previously fixed a c
This is a new DRM driver for Intel's KeemBay SOC.
The SoC couples an ARM Cortex A53 CPU with an Intel
Movidius VPU.
This driver is tested with the KMB EVM board which is the refernce baord
for Keem Bay SOC. The SOC's display pipeline is as follows
+--++-++-
== Series Details ==
Series: drm/i915: Don't try to check max stride for disabled/non-existent
display
URL : https://patchwork.freedesktop.org/series/80479/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8866_full -> Patchwork_18335_full
===
== Series Details ==
Series: drm/kmb: Add support for KeemBay Display (rev4)
URL : https://patchwork.freedesktop.org/series/79615/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7aaa226cd61c drm/kmb: Add support for KeemBay Display
-:58: WARNING:FILE_PATH_CHANGES: added, moved o
== Series Details ==
Series: drm/kmb: Add support for KeemBay Display (rev4)
URL : https://patchwork.freedesktop.org/series/79615/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8866 -> Patchwork_18336
Summary
---
**S
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2
selective fetch (rev2)
URL : https://patchwork.freedesktop.org/series/80478/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2
selective fetch (rev2)
URL : https://patchwork.freedesktop.org/series/80478/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bc91a045ae56 drm/i915: Initial implementation of PSR2
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2
selective fetch (rev2)
URL : https://patchwork.freedesktop.org/series/80478/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8866 -> Patchwork_18337
=
On Mon, Aug 10, 2020 at 02:45:52PM +0200, Maarten Lankhorst wrote:
> Op 16-07-2020 om 21:27 schreef Manasi Navare:
> > On Wed, Jul 15, 2020 at 03:42:17PM -0700, Manasi Navare wrote:
> >> From: Maarten Lankhorst
> >>
> >> Make vdsc work when no output is enabled. The big joiner needs VDSC
> >> on t
From: Maarten Lankhorst
Make vdsc work when no output is enabled. The big joiner needs VDSC
on the slave, so enable it and set the appropriate bits.
Also update timestamping constants, because slave crtc's are not
updated in drm_atomic_helper_update_legacy_modeset_state().
This should be enough
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system (rev3)
URL : https://patchwork.freedesktop.org/series/79534/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
94f4928909c8 HAX to make DSC work on the icelake test system
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system (rev3)
URL : https://patchwork.freedesktop.org/series/79534/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't b
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system (rev3)
URL : https://patchwork.freedesktop.org/series/79534/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8866 -> Patchwork_18338
== Series Details ==
Series: drm/kmb: Add support for KeemBay Display (rev4)
URL : https://patchwork.freedesktop.org/series/79615/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8866_full -> Patchwork_18336_full
Summary
On 8/7/2020 10:46 AM, john.c.harri...@intel.com wrote:
From: John Harrison
Update to the latest GuC firmware. This includes some significant
changes to the interface.
A high level overview of the changes would be nice for extra clarity. A
couple of example:
- GuC now requires a private m
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2
selective fetch (rev2)
URL : https://patchwork.freedesktop.org/series/80478/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8866_full -> Patchwork_18337_full
===
We usually assume that increasing PCI device revision ID's translates to
newer steppings; macros like IS_KBL_REVID() that we use rely on this
behavior. Unfortunately this turns out to not be true on KBL; the
newer device 2 revision ID's sometimes go backward to older steppings.
The situation is fu
Hi Matthew,
do you have a rebase of these or a git tree with them, once I hit the
PPGTT support applying started to get messy.
Dave.
On Fri, 10 Jul 2020 at 21:58, Matthew Auld wrote:
>
> This is Lucas' DG1 enabling series[1], plus some of the DG1 specific enablers
> for supporting LMEM on top,
== Series Details ==
Series: drm/i915/kbl: Fix revision ID checks (rev2)
URL : https://patchwork.freedesktop.org/series/80419/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2734daf22ac5 drm/i915/kbl: Fix revision ID checks
-:143: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev
== Series Details ==
Series: drm/i915/kbl: Fix revision ID checks (rev2)
URL : https://patchwork.freedesktop.org/series/80419/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
UNCORE_HAS_FORCEWAKE is not turned on when intel_vgpu_active() returns
true, so the guest mmio writes go to gen2_write32().
[ cut here ]
RPM raw-wakeref not held
WARNING: CPU: 1 PID: 6375 at drivers/gpu/drm/i915/intel_runtime_pm.h:106
gen2_write32+0x10b/0x140 [i915]
Mo
1 - 100 of 106 matches
Mail list logo
