== Series Details ==
Series: drm/i915/gt: Avoid uninitialized use of rpcurupei in frequency_show
URL : https://patchwork.freedesktop.org/series/76691/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8389_full -> Patchwork_17503_full
==
Hi Stephen,
On 4/29/20 12:33 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 20 Apr 2020 13:01:18 +1000 Stephen Rothwell
> wrote:
>>
>> After merging the drm-misc tree, today's linux-next build (powerpc
>> allyesconfig) failed like this:
>>
>> drivers/video/fbdev/controlfb.c: In function 'c
On Wed, 29 Apr 2020, Ville Syrjälä wrote:
> On Tue, Apr 28, 2020 at 11:27:50PM -0400, Alexei Podtelezhnikov wrote:
>> Add three new devices 0x1513, 0x1515, and 0x1517 also known as
>
> typo 0x15 vs. 0x19
>
>> iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. Reclassify 0x1923, 0x1927,
>> and 0x192A acco
On Tue, 28 Apr 2020, Michal Orzel wrote:
> As suggested by the TODO list for the kernel DRM subsystem, replace
> the deprecated functions that take/drop modeset locks with new helpers.
>
> Signed-off-by: Michal Orzel
> ---
> drivers/gpu/drm/drm_mode_object.c | 10 ++
> 1 file changed, 6
Chris doesn't like that.
v2: Don't forget to configure the kernel so that periodic reports are
written appropriately (Lionel)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 153 +
drivers/gpu/drm/i915/i915_perf_types.h | 10 +-
2 files
We want to enable performance monitoring on multiple contexts to cover
the Iris use case of using 2 GEM contexts (3D & compute).
So start by breaking the OA configuration BO which contains global &
per context register writes.
NOA muxes & OA configurations are global, while FLEXEU register
config
Hi all,
Just a small change on the key passed to bsearch().
Cheers,
Lionel Landwerlin (4):
drm/i915/perf: break OA config buffer object in 2
drm/i915/perf: stop using the kernel context
drm/i915/perf: prepare driver to receive multiple ctx handles
drm/i915/perf: enable filtering on multi
Make all the internal necessary changes before we flip the switch.
v2: Use an unlimited number of intel contexts (Chris)
v3: Handle GEM context with multiple RCS0 logical contexts (Chris)
v4: Let the intel_context create its own timeline (Chris)
Only pin configuration context when needed (Ch
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
This can be used by drivers using multiple GEM contexts to implement a
single GL context.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 58 ++
== Series Details ==
Series: drm/i915: Add PCI IDs for Skylake GT1.5 (rev2)
URL : https://patchwork.freedesktop.org/series/76577/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8389_full -> Patchwork_17504_full
Summary
-
From: Ville Syrjälä
Avoid the FBC_CONTROL rmw and just store the fbc compression
interval in the params/
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 13 ++---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
2 files changed, 8 insertions(+), 7 deletions
From: Ville Syrjälä
Parametrize the FBC_CONTROL bits for neater code.
Also add the one missing bit: "stop compression on modification".
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 8
drivers/gpu/drm/i915/i915_reg.h | 18 +++---
2
From: Ville Syrjälä
The hardware host tracking won't nuke the entire cfb (unless the
entire fb is written through the gtt) so don't clear the busy_bits
for gtt tracking.
Not that it really matters anymore since we've lost ORIGIN_GTT usage
everywhere.
Signed-off-by: Ville Syrjälä
---
drivers/g
From: Ville Syrjälä
The current fence_y_offset calculation is broken. I think it more or
less used to do the right thing, but then I changed the plane code
to put the final x/y source offsets back into the src rectangle so
now it's just subtraacting the same value from itself. The code would
neve
From: Ville Syrjälä
The MSG_FBC_REND_STATE register only exists on snb+. For older
platforms (would also work for snb+) we can simply rewite DSPSURF
to trigger a flip nuke.
While generally RMW is considered harmful we'll use it here for
simplicity. And since FBC doesn't exist in i830 we don't ha
From: Ville Syrjälä
Often we seem to detect an underrun right after modeset on gen2.
It seems to be a spurious detection (potentially the pipe is still
in a wonky state when we enable the planes). An extra vblank wait
seems to cure it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/disp
From: Ville Syrjälä
Consult the actual plane stride instead of the fb stride. The two
will disagree when we remap the gtt. The plane stride is what the
hw will be fed so that's what we should look at for the FBC
retrictions/cfb allocation.
Since we no longer require a fence we are going to attem
From: Ville Syrjälä
The default fbc1 compression interval we use is 500 frames. That
translates to over 8 seconds typically. That's rather excessive
so let's drop it to 1 second.
The hardware will not attempt recompression unless at least one
line has been modified, so a shorter compression inte
From: Ville Syrjälä
'level' here means the highest level we can't use, so when checking
the fbc watermarks we need a -1 to get at the last enabled level.
While at if refactor the code a bit to declutter
g4x_compute_pipe_wm().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c |
From: Ville Syrjälä
A bunch of FBC fixes. The most important thing is fixing glk+linear,
but included a pile of stuff I had lying about for older platforms
as well.
Ville Syrjälä (12):
drm/i915/fbc: Require linear fb stride to be multiple of 512 bytes on
gen9/glk
drm/i915/fbc: Use the co
From: Ville Syrjälä
Display WA #1105 says that FBC requires PLANE_STRIDE to be a multiple
of 512 bytes on gen9 and glk.
This is definitely true for glk as certain tests (such as
igt/kms_big_fb/linear-16bpp-rotate-0) are now failing when the
display resolution results in a plane stride which is n
From: Ville Syrjälä
Unlike all the other pre-snb desktop platforms i865 actually
supports FBC. Let's enable it.
Quote from the spec:
"DevSDG provides the same Run-Length Encoded Frame Buffer
Compression (RLEFBC) function as exists in DevMGM."
As i865 only has the one pipe we want to skip massa
From: Ville Syrjälä
Normally i85x/i865 3D activity will block FBC until a 2D blit
occurs. I suppose this was meant to avoid recompression while
3D activity is still going on but the frame hasn't yet been
presented. Unfortunately that also means that a page flipped
3D workload will permanently blo
== Series Details ==
Series: linux-next: build failure after merge of the drm-misc tree
URL : https://patchwork.freedesktop.org/series/76709/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4cb00cc7b2f7 linux-next: build failure after merge of the drm-misc tree
-:11: WARNING:COMM
== Series Details ==
Series: drm/i915/perf: Add support for multi context perf queries (rev3)
URL : https://patchwork.freedesktop.org/series/76588/
State : failure
== Summary ==
Applying: drm/i915/perf: break OA config buffer object in 2
Applying: drm/i915/perf: stop using the kernel context
A
As with the realisation for soft-rc6, we respond to idling the engines
within microseconds, far faster than the response times for HW RC6 and
RPS. Furthermore, our fast parking upon idle, prevents HW RPS from
running for many desktop workloads, as the RPS evaluation intervals are
on the order of te
We treat parking as a manual RPS timeout event, and downclock the GPU
for the next unpark and batch execution. However, having restored the
aggressive downclocking and observed that we have very light workloads
whose only interaction is through the manual parking events, carry over
the aggressive d
Pull the boolean intel_rps.enabled and intel_rps.active into a single
flags field, in preparation for more.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 5 +--
drivers/gpu/drm/i915/gt/intel_rps.c | 43 ++-
drivers
Use the new intel_rps.flags field to store whether or not interrupts are
being used with RPS.
Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_rps.c | 17 -
drivers/gpu/drm/i915/gt/intel_rps.h | 15 +++
drivers/gpu/drm
We reduced the clocks slowly after a boost event based on the
observation that the smoothness of animations suffered. However, since
reducing the evalution intervals, we should be able to respond to the
rapidly fluctuating workload of a simple desktop animation and so
restore the more aggressive do
In the near future, we will utilize the busy-stats on each engine to
approximate the C0 cycles of each, and use that as an input to a manual
RPS mechanism. That entails having busy-stats always enabled and so we
can remove the enable/disable routines and simplify the pmu setup. As a
consequence of
== Series Details ==
Series: linux-next: build failure after merge of the drm-misc tree
URL : https://patchwork.freedesktop.org/series/76709/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8390 -> Patchwork_17505
Summary
---
From: Ville Syrjälä
Replace the use of mode->private_flags with a truly private bitmaks
in our own crtc state. We also need a copy in the crtc itself so the
vblank code can get at it. We already have scanline_offset in there
for a similar reason, as well as the vblank->hwmode which is assigned
vi
From: Ville Syrjälä
There's no reason for I915_MODE_FLAG_INHERITED to exist as a flag
anymore. Just make it a boolean.
v2: Deal with sanitize_watermarks()
CC: Sam Ravnborg
Cc: Daniel Vetter
Cc: Emil Velikov
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/d
On 4/29/20 10:09 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi Stephen,
>
> On 4/29/20 12:33 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Mon, 20 Apr 2020 13:01:18 +1000 Stephen Rothwell
>> wrote:
>>>
>>> After merging the drm-misc tree, today's linux-next build (powerpc
>>> allyesconfig) fa
== Series Details ==
Series: drm/i915: FBC fixes
URL : https://patchwork.freedesktop.org/series/76714/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8390 -> Patchwork_17507
Summary
---
**SUCCESS**
No regressions f
== Series Details ==
Series: series starting with [CI,1/6] drm/i915/gt: Always enable busy-stats for
execlists
URL : https://patchwork.freedesktop.org/series/76715/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
081418e7ad56 drm/i915/gt: Always enable busy-stats for execlists
1
As we only restore the default context state upon banning a context, we
only need enough of the state to run the ring and nothing more. That is
we only need our bare protocontext.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel
We need to keep the default context state around to instantiate new
contexts (aka golden rendercontext), and we also keep it pinned while
the engine is active so that we can quickly reset a hanging context.
However, the default contexts are large enough to merit keeping in
swappable memory as oppos
== Series Details ==
Series: series starting with [CI,1/6] drm/i915/gt: Always enable busy-stats for
execlists
URL : https://patchwork.freedesktop.org/series/76715/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8390 -> Patchwork_17508
=
As we only restore the default context state upon banning a context, we
only need enough of the state to run the ring and nothing more. That is
we only need our bare protocontext.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel
== Series Details ==
Series: drm: Put drm_display_mode on diet (rev6)
URL : https://patchwork.freedesktop.org/series/73674/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
12add0e7c35a drm: Nuke mode->hsync
be723dfd05d8 drm/i915: Introduce some local intel_dp variables
fb85f7555a
Add three new devices 0x1913, 0x1915, and 0x1917 also known as
iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. Reclassify 0x1923, 0x1927,
and 0x192A according to specifications. Of note, the second to last
digit seems to correspond to GT#.
Signed-off-by: Alexei Podtelezhnikov
---
include/drm/i915_p
As we only restore the default context state upon banning a context, we
only need enough of the state to run the ring and nothing more. That is
we only need our bare protocontext.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel
On Wed, 29 Apr 2020, Ville Syrjälä wrote:
> On Tue, Apr 28, 2020 at 11:27:50PM -0400, Alexei Podtelezhnikov wrote:
>> Add three new devices 0x1513, 0x1515, and 0x1517 also known as
>
> typo 0x15 vs. 0x19
>
>> iSKLULTGT15, iSKLULXGT15, and iSKLDTGT15. Reclassify 0x1923, 0x1927,
>> and 0x192A accord
== Series Details ==
Series: drm: Put drm_display_mode on diet (rev6)
URL : https://patchwork.freedesktop.org/series/73674/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8390 -> Patchwork_17509
Summary
---
**SUCCESS*
Extend the timeout for pcode reads to 10ms as they should not be
performed along critical paths, and succeeding after a short delay is
better than failing entirely.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1800
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_sideb
We inadvertently create a dependency on mmap_sem with a whole chain.
This breaks any user who wants to take a lock and call rcu_barrier(),
while also taking that lock inside mmap_sem:
<4> [604.892532] ==
<4> [604.892534] WARNING: possible circul
From: Chris Wilson
Since the introduction of 'soft-rc6', we aim to park the device quickly
and that results in frequent idling of the whole device. Currently upon
idling we free the batch buffer pool, and so this renders the cache
ineffective for many workloads. If we want to have an effective ca
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 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 b39c24dae64e..e35e8d0b6938 100644
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.
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Maarten Lankhorst
---
.../gpu/d
The lock here should be interruptible, so we can backoff if needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i91
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_
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
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
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
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 9 -
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rend
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
This conflicts with the ww mutex handling, which needs to drop
the references after gpu submission anyway, because otherwise we
may risk unlocking a BO after first freeing it.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/
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
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 inserti
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(+),
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
drivers/g
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
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 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
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
---
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
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
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
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
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
== Series Details ==
Series: linux-next: build failure after merge of the drm-misc tree
URL : https://patchwork.freedesktop.org/series/76709/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8390_full -> Patchwork_17505_full
S
== Series Details ==
Series: drm/i915: Update Slylake PCI IDs
URL : https://patchwork.freedesktop.org/series/76720/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8391 -> Patchwork_17510
Summary
---
**SUCCESS**
No
Quoting Alexei Podtelezhnikov (2020-04-29 12:54:20)
> On Wed, 29 Apr 2020, Ville Syrjälä wrote:
> > On Tue, Apr 28, 2020 at 11:27:50PM -0400, Alexei Podtelezhnikov wrote:
> >> Add three new devices 0x1513, 0x1515, and 0x1517 also known as
> >
> > typo 0x15 vs. 0x19
> >
> >> iSKLULTGT15, iSKLULXGT1
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Keep a no-frills swappable
copy of the default context state (rev3)
URL : https://patchwork.freedesktop.org/series/76719/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
26b4faff2de3 drm/i915/gt: Keep a no-f
Hello Chris Wilson,
The patch 9c878557b1eb: "drm/i915/gt: Use the RPM config register to
determine clk frequencies" from Apr 24, 2020, leads to the following
static checker warning:
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c:407 frequency_show()
error: uninitialized symbol 'rpcurupei
If intel_context_create() fails then it leads to an error pointer
dereference. I shuffled things around to make error handling easier.
Fixes: 1dd47b54baea ("drm/i915: Add live selftests for indirect ctx
batchbuffers")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 30
Quoting Dan Carpenter (2020-04-29 14:23:45)
> Hello Chris Wilson,
>
> The patch 9c878557b1eb: "drm/i915/gt: Use the RPM config register to
> determine clk frequencies" from Apr 24, 2020, leads to the following
> static checker warning:
>
> drivers/gpu/drm/i915/gt/debugfs_gt_pm.c:407 frequ
On 28/04/2020 10:02, Chris Wilson wrote:
Once the intel_context is closed, the GEM context may be freed and so
the link from intel_context.gem_context is invalid.
<3>[ 219.782944] BUG: KASAN: use-after-free in
intel_engine_coredump_alloc+0x1bc3/0x2250 [i915]
<3>[ 219.782996] Read of size 8
== Series Details ==
Series: drm/i915: FBC fixes
URL : https://patchwork.freedesktop.org/series/76714/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8390_full -> Patchwork_17507_full
Summary
---
**FAILURE**
Seriou
drm_hdcp_check_ksvs_revoked() returns the number of revoked keys and
error codes when the SRM parsing is failed.
Errors in SRM parsing can't affect the HDCP auth, hence with this patch,
I915 will look out for revoked key count alone.
Signed-off-by: Ramalingam C
cc: Sean Paul
---
drivers/gpu/dr
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Keep a no-frills swappable
copy of the default context state (rev3)
URL : https://patchwork.freedesktop.org/series/76719/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8391 -> Patchwork_17511
On 2020-04-14 at 15:02:55 -0400, Sean Paul wrote:
> From: Sean Paul
>
> The SRM cleanup in 79643fddd6eb2 ("drm/hdcp: optimizing the srm
> handling") inadvertently altered the behavior of HDCP auth when
> the SRM firmware is missing. Before that patch, missing SRM was
> interpreted as the device h
Quoting Patchwork (2020-04-29 14:46:49)
> == Series Details ==
>
> Series: series starting with [CI,1/2] drm/i915/gt: Keep a no-frills swappable
> copy of the default context state (rev3)
> URL : https://patchwork.freedesktop.org/series/76719/
> State : failure
>
> == Summary ==
>
> CI Bug Lo
Quoting Dan Carpenter (2020-04-29 14:24:25)
> If intel_context_create() fails then it leads to an error pointer
> dereference. I shuffled things around to make error handling easier.
>
> Fixes: 1dd47b54baea ("drm/i915: Add live selftests for indirect ctx
> batchbuffers")
> Signed-off-by: Dan Car
== Series Details ==
Series: drm/i915: Allow some leniency in PCU reads
URL : https://patchwork.freedesktop.org/series/76723/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8391 -> Patchwork_17512
Summary
---
**SUCCES
On Wed, Apr 29, 2020 at 9:50 AM Ramalingam C wrote:
>
> On 2020-04-14 at 15:02:55 -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > The SRM cleanup in 79643fddd6eb2 ("drm/hdcp: optimizing the srm
> > handling") inadvertently altered the behavior of HDCP auth when
> > the SRM firmware is missing
== Series Details ==
Series: series starting with [01/25] perf/core: Only copy-to-user after
completely unlocking all locks, v3.
URL : https://patchwork.freedesktop.org/series/76724/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fafe194bca56 perf/core: Only copy-to-user after
Hi Dan,
On Wed, Apr 29, 2020 at 04:24:25PM +0300, Dan Carpenter wrote:
> If intel_context_create() fails then it leads to an error pointer
> dereference. I shuffled things around to make error handling easier.
>
> Fixes: 1dd47b54baea ("drm/i915: Add live selftests for indirect ctx
> batchbuffer
Quoting Tvrtko Ursulin (2020-04-29 14:42:44)
>
> On 28/04/2020 10:02, Chris Wilson wrote:
> > Once the intel_context is closed, the GEM context may be freed and so
> > the link from intel_context.gem_context is invalid.
> >
> > <3>[ 219.782944] BUG: KASAN: use-after-free in
> > intel_engine_cor
On 2020-04-29 at 09:58:16 -0400, Sean Paul wrote:
> On Wed, Apr 29, 2020 at 9:50 AM Ramalingam C wrote:
> >
> > On 2020-04-14 at 15:02:55 -0400, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > The SRM cleanup in 79643fddd6eb2 ("drm/hdcp: optimizing the srm
> > > handling") inadvertently altere
== Series Details ==
Series: series starting with [01/25] perf/core: Only copy-to-user after
completely unlocking all locks, v3.
URL : https://patchwork.freedesktop.org/series/76724/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8391 -> Patchwork_17513
===
== Series Details ==
Series: series starting with [CI,1/6] drm/i915/gt: Always enable busy-stats for
execlists
URL : https://patchwork.freedesktop.org/series/76715/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8390_full -> Patchwork_17508_full
===
On Wed, Apr 29, 2020 at 10:22 AM Ramalingam C wrote:
>
> On 2020-04-29 at 09:58:16 -0400, Sean Paul wrote:
> > On Wed, Apr 29, 2020 at 9:50 AM Ramalingam C wrote:
> > >
> > > On 2020-04-14 at 15:02:55 -0400, Sean Paul wrote:
> > > > From: Sean Paul
> > > >
> > > > The SRM cleanup in 79643fddd6eb
On Wed, Apr 29, 2020 at 9:46 AM Ramalingam C wrote:
>
> drm_hdcp_check_ksvs_revoked() returns the number of revoked keys and
> error codes when the SRM parsing is failed.
>
> Errors in SRM parsing can't affect the HDCP auth, hence with this patch,
> I915 will look out for revoked key count alone.
Wait until the GPU is idle before starting a fresh round of probing
gen8-unprivileged-single-ctx-counter. This avoids building up a huge
backlog of render copies, hogging buffers and stale contexts, and
invoking the oomkiller.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
tests/perf.c |
== Series Details ==
Series: drm/i915/selftests: fix error handling in __live_lrc_indirect_ctx_bb()
URL : https://patchwork.freedesktop.org/series/76727/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8391 -> Patchwork_17514
Oh... Is that on a low end platform?
Looks alright :
Reviewed-by: Lionel Landwerlin
Thanks,
-Lionel
On 29/04/2020 17:51, Chris Wilson wrote:
Wait until the GPU is idle before starting a fresh round of probing
gen8-unprivileged-single-ctx-counter. This avoids building up a huge
backlog of re
Quoting Lionel Landwerlin (2020-04-29 15:57:41)
> Oh... Is that on a low end platform?
glk. But it was mostly that it got stuck in the rut of hitting -EAGAIN.
/* This needs to be investigated... From time
* to time, the work we kick off doesn't seem
* to happen. WTH?? */
Hmm. And that's before
1 - 100 of 179 matches
Mail list logo
