On 18.02.2020 22:21, James Morris wrote:
> On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
>>
>> Introduce CAP_PERFMON capability designed to secure system performance
>> monitoring and observability operations so that CAP_PERFMON would assist
>> CAP_SYS_ADMIN capability in its governing role for
On 2/18/20 10:01 PM, Daniel Vetter wrote:
On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
wrote:
On 2/17/20 6:55 PM, Daniel Vetter wrote:
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
Implement the importer side of unpinned DMA-buf handling.
v2: update page table
== Series Details ==
Series: drm/i915: Extend Wa_1606931601 for all steppings.
URL : https://patchwork.freedesktop.org/series/73621/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16616
Summary
---
*
== Series Details ==
Series: drm/i915: Extend Wa_1606931601 for all steppings.
URL : https://patchwork.freedesktop.org/series/73621/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ac9882b75ddf drm/i915: Extend Wa_1606931601 for all steppings.
-:11: ERROR:GIT_COMMIT_ID: Please us
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display: Deactive FBC in
fastsets when disabled by parameter
URL : https://patchwork.freedesktop.org/series/73618/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16615
===
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73615/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16614
Summary
---
**SUCCES
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display: Deactive FBC in
fastsets when disabled by parameter
URL : https://patchwork.freedesktop.org/series/73618/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a2421f8f2be7 drm/i915/display: Deactive FBC in f
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73615/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Add mechanism to submit a context WA on ring submission
Okay!
Commit
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73615/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e5b3c3f78307 drm/i915: Add mechanism to submit a context WA on ring submission
bead3540e24e drm/i915/gen7:
== Series Details ==
Series: drm/i915/tgl: Remove require_force_probe protection
URL : https://patchwork.freedesktop.org/series/73613/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16613
Summary
---
== Series Details ==
Series: drm/i915/gt/tgl: implement Wa_1409085225
URL : https://patchwork.freedesktop.org/series/73611/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16612
Summary
---
**FAILURE*
Previously known by the WA number - Wa_1607090982, extend
the WA (Disable Early Read and Src Swap (bit 14) by
setting the chicken register.) to all steppings.
The WA is implemented in -
3873fd1a43c7 ("drm/i915: Use engine wa list for Wa_1607090982")
Bspec: 46045,52890
Cc: Mika Kuoppala
Signed-o
== Series Details ==
Series: series starting with [CI,01/10] drm/i915/debugfs: Pass guc_log struct
to i915_guc_log_info
URL : https://patchwork.freedesktop.org/series/73610/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16611
== Series Details ==
Series: series starting with [CI,01/10] drm/i915/debugfs: Pass guc_log struct
to i915_guc_log_info
URL : https://patchwork.freedesktop.org/series/73610/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c9413e3a8cde drm/i915/debugfs: Pass guc_log struct to i91
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST connectors (rev4)
URL : https://patchwork.freedesktop.org/series/70393/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16610
Summary
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST connectors (rev4)
URL : https://patchwork.freedesktop.org/series/70393/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
00144368762c drm/i915: Fix sha_text population code
-:60: WARNING:LINE_SPACING: Missing
== Series Details ==
Series: series starting with [1/1] drm/i915: MCHBAR memory info registers are
moved since GEN 12. (rev3)
URL : https://patchwork.freedesktop.org/series/73332/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16609
==
== Series Details ==
Series: drm/i915/psr: Force PSR probe only after full initialization (rev5)
URL : https://patchwork.freedesktop.org/series/73436/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16607
Su
== Series Details ==
Series: drm/i915/selftests: Flush tasklet on wait_for_submit()
URL : https://patchwork.freedesktop.org/series/73605/
State : failure
== Summary ==
Applying: drm/i915/selftests: Flush tasklet on wait_for_submit()
Using index info to reconstruct a base tree...
M driver
== Series Details ==
Series: drm/i915/gt: Protect signaler walk with RCU
URL : https://patchwork.freedesktop.org/series/73601/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16606
Summary
---
**SUCCE
Most of the kms_frontbuffer_tracking tests disables the feature being
tested, draw, get the CRC then enable the feature, draw again, get the
CRC and check if it matches.
Some times it is able to do that with a fastset, so
intel_pre_plane_update() is executed but intel_fbc_can_flip_nuke() was
not ch
From: Radhakrishna Sripada
Platforms without fences don't have FBC host tracking and those
registers are marked as reserved in those platforms.
v2: checking num_fences to write to FBC fence registers (Ville)
Cc: Rodrigo Vivi
Cc: Matt Roper
Cc: Dhinakaran Pandiyan
Cc: Ville Syrjälä
Reviewed-
dGFX have local memory so it do not have aperture and do not support
CPU fences but even for iGFX it have a small number of fences.
As replacement for fences to track frontbuffer modifications by CPU
we have a software tracking that is already in used by FBC and PSR.
PSR don't support fences so it
== Series Details ==
Series: drm/i915/perf: conversion to struct drm_device based logging macros.
URL : https://patchwork.freedesktop.org/series/73589/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16605
S
On Tue, Feb 18, 2020 at 03:08:22PM -0800, José Roberto de Souza wrote:
> We have a few TGL machines in our CI and it is mostly green with
> failures in tests that will not impact future Linux installations.
> Also there is no warnings, errors, flickering or any visual defects
> while doing ordinary
== Series Details ==
Series: drm/i915/perf: conversion to struct drm_device based logging macros.
URL : https://patchwork.freedesktop.org/series/73589/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2da597adb589 drm/i915/perf: conversion to struct drm_device based logging
macro
== Series Details ==
Series: drm/i915: make i915_debugfs_register return void.
URL : https://patchwork.freedesktop.org/series/73587/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16604
Summary
---
*
On Tue, Feb 18, 2020 at 03:44:49PM -0800, Rafael Antognolli wrote:
> On Tue, Feb 18, 2020 at 02:47:10PM -0500, Matt Atwood wrote:
> > Disable Push Constant buffer addition for A0, which can cause FIFO
> > underruns.
> >
> > Fix a minor white space issue while we're here.
> >
> > Bspec: 52890
> >
== Series Details ==
Series: series starting with [1/5] dma-buf: add dynamic DMA-buf handling v14
URL : https://patchwork.freedesktop.org/series/73586/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16603
S
On Tue, Feb 18, 2020 at 02:47:10PM -0500, Matt Atwood wrote:
> Disable Push Constant buffer addition for A0, which can cause FIFO
> underruns.
>
> Fix a minor white space issue while we're here.
>
> Bspec: 52890
> Cc: Rafael Antognolli
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/
Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615
Summary of Vulnerability
Insufficient control flow in certain data structures for some Intel(R)
Processors with Intel Processor Graphics may allow an unauthenticated
user to potentially enable information disclosure via l
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each conte
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require
== Series Details ==
Series: series starting with [1/5] dma-buf: add dynamic DMA-buf handling v14
URL : https://patchwork.freedesktop.org/series/73586/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c9c2d1477530 dma-buf: add dynamic DMA-buf handling v14
-:10: WARNING:COMMIT_LOG_
We have a few TGL machines in our CI and it is mostly green with
failures in tests that will not impact future Linux installations.
Also there is no warnings, errors, flickering or any visual defects
while doing ordinary tasks like browsing and editing documents in a
dual monitor setup.
As a remin
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to monitoring via kprobes and uprobes and eBPF tracing for
> CAP_PERFMON privileged process. Providing the access under CAP_PERFMON
> capability singly, without the rest of CAP_SYS_ADMIN credentials,
> excludes chances to misuse the cred
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to bpf_trace monitoring for CAP_PERFMON privileged process.
> Providing the access under CAP_PERFMON capability singly, without the
> rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
> credentials and makes operation mor
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey Budank
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey Budank
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to monitoring of kernel code, cpus, tracepoints and
> namespaces data for a CAP_PERFMON privileged process. Providing the
> access under CAP_PERFMON capability singly, without the rest of
> CAP_SYS_ADMIN credentials, excludes chances to
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey Budank
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Open access to i915_perf monitoring for CAP_PERFMON privileged process.
> Providing the access under CAP_PERFMON capability singly, without the
> rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
> credentials and makes operation mor
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Extend error messages to mention CAP_PERFMON capability as an option
> to substitute CAP_SYS_ADMIN capability for secure system performance
> monitoring and observability. Make perf_event_paranoid_check() and
> __cmd_ftrace() to be aware of CAP_PERF
On Mon, 17 Feb 2020, Alexey Budankov wrote:
> For backward compatibility reasons access to the monitoring remains
> open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
> for secure monitoring is discouraged with respect to CAP_PERFMON
> capability.
>
> Signed-off-by: Alexey Budank
On Mon, 17 Feb 2020, Alexey Budankov wrote:
>
> Introduce CAP_PERFMON capability designed to secure system performance
> monitoring and observability operations so that CAP_PERFMON would assist
> CAP_SYS_ADMIN capability in its governing role for performance
> monitoring and observability subsyst
== Series Details ==
Series: kernel 5.5.4: BUG: kernel NULL pointer dereference, address:
000 (rev2)
URL : https://patchwork.freedesktop.org/series/73585/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
053c95b596f5 kernel 5.5.4: BUG: kernel NULL pointer dereference,
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73584/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963 -> Patchwork_16601
Summary
---
**SUCCESS**
No regr
Disable Push Constant buffer addition for A0, which can cause FIFO
underruns.
Fix a minor white space issue while we're here.
Bspec: 52890
Cc: Rafael Antognolli
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 ++
drivers/gpu/drm/i915/i915_reg.h
== Series Details ==
Series: drm/i915: Read rawclk_freq earlier
URL : https://patchwork.freedesktop.org/series/73507/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7950_full -> Patchwork_16591_full
Summary
---
**SUCC
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73584/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Start passing latency as parameter
Okay!
Commit: drm/i915: Introduce skl_plane_wm_
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73584/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1c72d442abeb drm/i915: Start passing latency as parameter
b0f9bed0c1be drm/i915: Introduce skl_plane_wm_level accessor.
To be able to differentiate the before and after of our commitment to
GuC submission, which will be used in follow-up patches to early set-up
the submission structures.
v2: move functions to guc_submission.h (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Reviewed-by: John H
To enable GuC and HuC loading on all gen9+ CI machines.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 45323732f099..7b
We are quite trigger happy in cleaning up the firmware blobs, as we do
so from several error/fini paths in GuC/HuC/uC code. We do have the
__uc_cleanup_firmwares cleanup function, which unwinds
__uc_fetch_firmwares and is already called both from the error path of
gem_init and from gem_driver_relea
Now that we can differentiate wants vs uses GuC/HuC, intel_uc_init is
restricted to running only if we have successfully fetched the required
blob(s) and are committed to using the microcontroller(s).
The only remaining thing that can go wrong in uc_init is the allocation
of GuC/HuC related objects
To be able to setup GuC submission functions during engine init we need
to commit to using GuC as soon as possible.
Currently, the only thing that can stop us from using the
microcontrollers once we've fetched the blobs is a fundamental
error (e.g. OOM); given that if we hit such an error we can't
use intel_uc_uses_guc() directly instead, to be consistent in the way we
check what we want to do with the GuC.
v2: split guc_log_info changes to their own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by: Michal Wajdecz
We want to map uC-level checks to GuC/HuC-level ones. The mapping from
the uC state to the GuC/HuC one follows the same pattern for all the
functions:
uc_xxx_guc() -> guc_is_yyy()
So we can easily use a macro to autogenerate the functions via macros by
passing in the 2 mapped states.
v2: Split
The log struct is the only thing the function needs (apart from
the seq_file), so we can pass just that instead of the whole dev_priv.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by: Mi
use intel_uc_uses_guc_submission() directly instead, to be consistent in
the way we check what we want to do with the GuC.
v2: do not go through ctx->vm->gt, use i915->gt instead
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by: Michal
In a follow up patch we will rely on the fact that the status always
moves away from "SELECTED" after the fetch is attempted to decide what
to do with the GuC.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matth
On 19/02/2020 00:03, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-02-18 21:54:03)
On 16/02/2020 18:17, Chris Wilson wrote:
Since we use a HW readback or estimation of the CS timestamp frequency,
sometimes it may result in 0. Avoid the division-by-zero in computing
its reciprocal, the tim
On Sun, Feb 2, 2020 at 2:03 PM Ramalingam C wrote:
>
> On 2020-01-17 at 14:30:59 -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch is required for HDCP over MST. If a port is being used for
> > multiple HDCP streams, we don't want to fully disable HDCP on a port if
> > one of them is
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Cc: Juston Li
Signed-off-by: Sean Paul
Link:
https://patchwork.freed
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Cc: Lyude Paul
Signed-off-by: Sean Paul
Changes in v4:
-Added to the set
---
drivers/gpu/drm/drm_dp_mst_topology.c | 117 ++
include/drm/drm_dp_helper.h | 3 +
include/drm/drm_dp_mst_
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
https://patchwork.freedesk
From: Sean Paul
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
Sign
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
Link
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't do
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being pla
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Pa
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an L
From: Sean Paul
Hey all,
Back with a v4. Rebased on latest drm-tip.
Biggest change was adding the QUERY_STREAM_ENCRYPTION_STATUS check which
ensures not only the link to the first branch is encrypted, but also
that the channel iteself is also protected.
Sean
Sean Paul (14):
drm/i915: Fix sh
From: Sean Paul
HDCP signalling should not be left on, WARN if it is
Cc: Ville Syrjälä
Cc: Daniel Vetter
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.o
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Pa
Quoting Lionel Landwerlin (2020-02-18 21:54:03)
> On 16/02/2020 18:17, Chris Wilson wrote:
> > Since we use a HW readback or estimation of the CS timestamp frequency,
> > sometimes it may result in 0. Avoid the division-by-zero in computing
> > its reciprocal, the timestamp period.
> >
> > Signed-o
On 16/02/2020 18:17, Chris Wilson wrote:
Since we use a HW readback or estimation of the CS timestamp frequency,
sometimes it may result in 0. Avoid the division-by-zero in computing
its reciprocal, the timestamp period.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_device_info.c
== Series Details ==
Series: series starting with [01/12] drm/i915/selftests: Check for any sign of
request starting in wait_for_submit()
URL : https://patchwork.freedesktop.org/series/73583/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7962 -> Patchwork_16600
==
== Series Details ==
Series: drm/i915: Avoid potential division-by-zero in computing CS timestamp
period
URL : https://patchwork.freedesktop.org/series/73506/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7950_full -> Patchwork_16590_full
=
Quoting Daniele Ceraolo Spurio (2020-02-18 21:24:47)
>
>
> On 2/18/20 8:21 AM, Chris Wilson wrote:
> > On dgfx, we only use l3cc and not mocs, but we share the table of
> > register definitions with Tigerlake (which includes the mocs). This
-share the table of register definitions
+share the tab
On 2/18/20 8:21 AM, Chris Wilson wrote:
On dgfx, we only use l3cc and not mocs, but we share the table of
register definitions with Tigerlake (which includes the mocs). This
Just a small correction here: the problem is not that the Tigerlake
definitions will be shared (which is not necessar
== Series Details ==
Series: series starting with [01/12] drm/i915/selftests: Check for any sign of
request starting in wait_for_submit()
URL : https://patchwork.freedesktop.org/series/73583/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
181edb75b6c9 drm/i915/gt: Show the cumu
Always flush the tasklet if we have pending submissions in
wait_for_submit(), so that even if we see the HW has started before we
process its ack, when we return the execlists state is well defined.
Fixes: 06289949b8dd ("drm/i915/selftests: Check for any sign of request
starting in wait_for_submi
On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
wrote:
>
> On 2/17/20 6:55 PM, Daniel Vetter wrote:
> > On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
> >> Implement the importer side of unpinned DMA-buf handling.
> >>
> >> v2: update page tables immediately
> >>
> >> S
== Series Details ==
Series: drm/i915/selftests: Check for any sign of request starting in
wait_for_submit()
URL : https://patchwork.freedesktop.org/series/73572/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7961 -> Patchwork_16599
===
== Series Details ==
Series: drm/i915/selftests: Fix selftest_mocs for DGFX (rev3)
URL : https://patchwork.freedesktop.org/series/73387/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7950_full -> Patchwork_16589_full
Summar
On Tue, 18 Feb 2020 at 16:22, Chris Wilson wrote:
>
> As we have the total runtime known to us, show it when dumping the
> engine state for debug.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.free
On Tue, 18 Feb 2020 at 16:22, Chris Wilson wrote:
>
> As setup takes a long time, the user may close the context during the
> construction of the execbuf. In order to make sure we correctly track
> all outstanding work with non-persistent contexts, we need to serialise
> the submission with the co
Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
once to enable PSR") was forcing the state compute too earlier
causing errors because not everything was initialized, so here
moving to i915_driver_register() when everything is ready and driver
is registering into the rest of th
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed by the HW and retired as we process
this request. Ergo we need to use rcu to protect the list iteration and
remember to mark up the
On Tue, 18 Feb 2020 at 16:22, Chris Wilson wrote:
>
> If a context is banned even before we submit our first request to it,
> report the failure before we attempt to allocate any resources for the
> context.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
__
On Tue, 18 Feb 2020 at 16:22, Chris Wilson wrote:
>
> Just missed setting err along an interruptible error path for the
> intel_engine_pulse().
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedes
== Series Details ==
Series: drm/i915/selftests: Check for any sign of request starting in
wait_for_submit()
URL : https://patchwork.freedesktop.org/series/73572/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
261fc108dea2 drm/i915/selftests: Check for any sign of request start
On 2/17/20 6:55 PM, Daniel Vetter wrote:
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
Implement the importer side of unpinned DMA-buf handling.
v2: update page tables immediately
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66
== Series Details ==
Series: series starting with [1/6] drm/i915/gt: Show the cumulative context
runtime in engine debug (rev3)
URL : https://patchwork.freedesktop.org/series/73567/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7961 -> Patchwork_16598
On Tue, 18 Feb 2020 at 16:22, Chris Wilson wrote:
>
> We only want to wait until the request has been submitted at least once;
> that is it is either in flight, or has been.
>
> References: fcf7df7aae24 ("drm/i915/selftests: Check for the error interrupt
> before we wait!")
> Signed-off-by: Chris
== Series Details ==
Series: series starting with [1/6] drm/i915/gt: Show the cumulative context
runtime in engine debug (rev3)
URL : https://patchwork.freedesktop.org/series/73567/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e1dc2d81cb6a drm/i915/gt: Show the cumulative con
1 - 100 of 174 matches
Mail list logo
