== Series Details ==
Series: drm/i915/psr: Execute the default PSR code path when setting
i915_edp_psr_debug (rev3)
URL : https://patchwork.freedesktop.org/series/56013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5522_full -> Patchwork_12115_full
==
== Series Details ==
Series: drm/i915: Allow normal clients to always preempt idle priority clients
URL : https://patchwork.freedesktop.org/series/56072/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5522_full -> Patchwork_12114_full
===
== Series Details ==
Series: drm/i915/cfl: Adding another PCI Device ID.
URL : https://patchwork.freedesktop.org/series/56075/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5522 -> Patchwork_12116
Summary
---
**SUCCE
Hi,
This should be last gvt-next pull for this round, which adds VFIO edid
region support in GVT, VM manager can use this to specify custom EDID
for VM, which can be used for e.g UI resize, etc.
p.s, Next week will be chinese new year, so team will be offline then.
Thanks.
--
The following chan
== Series Details ==
Series: drm/i915/cfl: Adding another PCI Device ID.
URL : https://patchwork.freedesktop.org/series/56075/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ab594f4fdd62 drm/i915/cfl: Adding another PCI Device ID.
-:13: WARNING:BAD_SIGN_OFF: email address 'Dmitr
While cross checking PCI IDs from Intel Media SDK
and kernel Dmitry noticed this gap. So we checked the
spec and this new ID had been recently added.
Reported-by: Dmitry Rogozhkin
Cc: Dmitry Rogozhkin
Cc: José Roberto de Souza
Signed-off-by: Rodrigo Vivi
---
include/drm/i915_pciids.h | 4
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 3f287cb6d4ae4689eb7c53e4c25f0fba3df16438
commit: 0a2fe4901d16d28bb8ad5f7032e9579f85e7e594 [891/897] Merge
remote-tracking branch 'drm/drm-next' into drm-tip
config: riscv-allmodconfig (attached as .config)
compiler: riscv64-linux-gc
== Series Details ==
Series: restore WaEnableFloatBlendOptimization
URL : https://patchwork.freedesktop.org/series/56071/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5521_full -> Patchwork_12113_full
Summary
---
**
== Series Details ==
Series: CRTC background color (rev6)
URL : https://patchwork.freedesktop.org/series/50834/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5521_full -> Patchwork_12112_full
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/psr: Execute the default PSR code path when setting
i915_edp_psr_debug (rev3)
URL : https://patchwork.freedesktop.org/series/56013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5522 -> Patchwork_12115
== Series Details ==
Series: drm/i915: Allow normal clients to always preempt idle priority clients
URL : https://patchwork.freedesktop.org/series/56072/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5522 -> Patchwork_12114
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs
URL : https://patchwork.freedesktop.org/series/56059/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5520_full -> Patchwork_12111_full
S
== Series Details ==
Series: drm/i915: Allow normal clients to always preempt idle priority clients
URL : https://patchwork.freedesktop.org/series/56072/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Allow normal clients to always preempt id
== Series Details ==
Series: drm/i915: Allow normal clients to always preempt idle priority clients
URL : https://patchwork.freedesktop.org/series/56072/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0f047db61683 drm/i915: Allow normal clients to always preempt idle priority
c
On Thu, 2019-01-31 at 10:34 +0100, Maarten Lankhorst wrote:
> Op 31-01-2019 om 01:58 schreef José Roberto de Souza:
> > Changing the i915_edp_psr_debug was enabling, disabling or
> > switching
> > PSR version by directly calling intel_psr_disable_locked() and
> > intel_psr_enable_locked(), what is
Changing the i915_edp_psr_debug was enabling, disabling or switching
PSR version by directly calling intel_psr_disable_locked() and
intel_psr_enable_locked(), what is not the default PSR path that will
be executed by real users.
So lets force a fastset in the PSR CRTC to trigger a pipe update and
== Series Details ==
Series: restore WaEnableFloatBlendOptimization
URL : https://patchwork.freedesktop.org/series/56071/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5521 -> Patchwork_12113
Summary
---
**SUCCESS**
When first enabling preemption, we hesitated from making it a free-for-all
where every higher priority client would force a preempt-to-idle cycle
and take over from all lower priority clients. We hesitated because we
were uncertain just how well preemption would work in practice, whether
the preemp
Quoting Talha Nassar (2019-02-01 01:08:44)
> Enables blend optimization for floating point RTs
>
> This restores the workaround that was reverted in c358514ba8da
> ("Revert "drm/i915/icl: WaEnableFloatBlendOptimization"").
>
> The revert was due to the register write seemingly not sticking,
> but
Quoting Talha Nassar (2019-02-01 01:08:42)
> From: Tvrtko Ursulin
>
> Top comment in intel_workarounds.c says common code should come first so
> lets respect that. Also, by moving the common code together opportunities
> to reduce duplication will become more obvious.
>
> Signed-off-by: Tvrtko U
== Series Details ==
Series: restore WaEnableFloatBlendOptimization
URL : https://patchwork.freedesktop.org/series/56071/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5ff28df401d6 drm/i915: Move workaround infrastructure code up
3724f3bfa9a7 drm/i915: Save some lines of source
This fixes the extra issues I discovered upstream after the introduction
of my rework of the atomic VCPI helpers that occur during
suspend/resume.
This time around, we use a slightly different but much less complicated
approach for fixing said issues.
Cc: Daniel Vetter
Lyude Paul (4):
drm/dp_
From: Tvrtko Ursulin
No functional or code size change - just notice we can compact the source
by re-using a single helper for adding workarounds.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_workarounds.c | 32 ++--
1 file
This is the v2 of my patch after taking the feed from Chris. I have also
included the HSDES per Mika's suggestion.
I am attaching the two-patch series from Tvrtko as there is a dependency.
Also to note that git couldn't apply Tvrtko's first patch due to a patch by
Daniele that touched the same fi
Enables blend optimization for floating point RTs
This restores the workaround that was reverted in c358514ba8da
("Revert "drm/i915/icl: WaEnableFloatBlendOptimization"").
The revert was due to the register write seemingly not sticking,
but the HW team has confirmed that this is because the
regis
From: Tvrtko Ursulin
Top comment in intel_workarounds.c says common code should come first so
lets respect that. Also, by moving the common code together opportunities
to reduce duplication will become more obvious.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_workarounds.c | 7
Since we now have an easy way of refcounting drm_dp_mst_port structs and
safely accessing their contents, there isn't any good reason to keep
validating ports here. It doesn't prevent us from performing modesets on
branch devices that have been removed either, and we already disallow
enabling new d
== Series Details ==
Series: CRTC background color (rev6)
URL : https://patchwork.freedesktop.org/series/50834/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5521 -> Patchwork_12112
Summary
---
**SUCCESS**
No regr
== Series Details ==
Series: CRTC background color (rev6)
URL : https://patchwork.freedesktop.org/series/50834/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm: Add CRTC background color property (v5)
Okay!
Commit: drm/i915/gen9+: Add support for p
== Series Details ==
Series: CRTC background color (rev6)
URL : https://patchwork.freedesktop.org/series/50834/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8c549af67706 drm: Add CRTC background color property (v5)
-:239: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'shift' - p
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready to
We should support readout and verification of crtc background color as
we do with other pipe state. Note that our hardware holds less bits of
precision than the CRTC state allows, so we need to take care to only
verify the most significant bits of the color after performing readout.
At boot time
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background
Previous patch series/discussion was here:
https://lists.freedesktop.org/archives/dri-devel/2019-January/205504.html
Reviewed userspace (chromeos) is here:
https://chromium-review.googlesource.com/c/chromium/src/+/1278858
https://chromium-review.googlesource.com/c/chromiumos/platform/drm-te
== Series Details ==
Series: drm/i915: do not return invalid pointers as a *dentry
URL : https://patchwork.freedesktop.org/series/56044/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518_full -> Patchwork_12110_full
Summar
On Wed, 2019-01-30 at 16:58 -0800, José Roberto de Souza wrote:
> Changing the i915_edp_psr_debug was enabling, disabling or switching
> PSR version by directly calling intel_psr_disable_locked() and
> intel_psr_enable_locked(), what is not the default PSR path that will
> be executed by real users
Quoting Patchwork (2019-01-31 22:33:09)
> Possible regressions
>
> * igt@gem_eio@unwedge-stress:
> - shard-snb: PASS -> FAIL
Old, random 2s delay.
> Possible fixes
>
> * igt@gem_eio@reset-stress:
> - shard-hsw: INCOMPLETE [fdo#103540] / [fdo#109
== Series Details ==
Series: series starting with drm/i915: Revoke mmaps and prevent access to fence
registers across reset (rev4)
URL : https://patchwork.freedesktop.org/series/56042/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5518_full -> Patchwork_12109_full
===
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev29)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518_full -> Patchwork_12106_full
Summary
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs
URL : https://patchwork.freedesktop.org/series/56059/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5520 -> Patchwork_12111
Summary
---
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs
URL : https://patchwork.freedesktop.org/series/56059/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
Okay!
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs
URL : https://patchwork.freedesktop.org/series/56059/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
646f25f459f0 drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
-:20: WARNING:TABSTOP
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for t
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP H
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
This patches are RFC patches that add a VSC structure for handling
Pixel Encodi
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/
pipe_bpp value was assumed RGB therefore it was multiplied with 3.
But YCbCr 4:2:0 requires multiplier value to 1.5 therefore it divides
pipe_bpp to 2.
- RGB bpp = bpc x 3
- YCbCr 4:2:0 bpp = bpc x 1.5
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/intel_ddi.c | 7 +-
drivers/gpu
SDP VSC Header and Data Block follow DP 1.4a spec, section 2.2.5.7.5,
chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
Signed-off-by: Gwan-gyeong Mun
---
include/drm/drm_dp_helper.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/drm/drm_dp_helper.h
== Series Details ==
Series: series starting with [1/4] drm/i915: Enable transition watermarks for
glk
URL : https://patchwork.freedesktop.org/series/56025/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5518_full -> Patchwork_12103_full
===
== Series Details ==
Series: drm/i915: Implement HDCP2.2 (rev13)
URL : https://patchwork.freedesktop.org/series/38254/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5517_full -> Patchwork_12101_full
Summary
---
**SUC
On Thu, Jan 31, 2019 at 09:59:26AM -0800, Rodrigo Vivi wrote:
> On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, they can now return error values if
> > something went wrong. If that happens, return a NULL as a *dentry to
> > the relay core in
On Thu, Jan 31, 2019 at 09:42:16AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Drop WaIncreaseLatencyIPCEnabled/Display w/a #1140 for
> early cnl steppings. Also switch the kbl/cfl case to check
> for IS_GEN9_BC() for brevity. It ends up being the same thing
> because IPC is disabled on
On Thu, Jan 31, 2019 at 09:42:15AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Display w/a #1141 is also known as WaIncreaseLatencyIPCEnabled.
> Add that to the comment.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_pm.c | 5 -
>
On Thu, Jan 31, 2019 at 09:42:14AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Display w/a #1140 tells us we have to program the transition
> watermark to the minimum value on glk/cnl. Let's do that.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/dr
On Thu, Jan 31, 2019 at 09:42:13AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We are mistakenly skipping transition watermarks on glk. Fix
> up the condition for glk, and toss in the w/a name from
> the database.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
>
On Thu, Jan 24, 2019 at 01:40:48PM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here is gvt-next stuff. This includes Coffeelake support for GVT,
> making kvmgt as self load module to have better dependence with
> vfio/mdev, with some const treatment and kernel type change.
ops, I also failed to let yo
On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, they can now return error values if
> something went wrong. If that happens, return a NULL as a *dentry to
> the relay core instead of passing it an illegal pointer.
>
> The relay core should be
Quoting Tvrtko Ursulin (2019-01-31 13:19:31)
>
> On 30/01/2019 02:19, Chris Wilson wrote:
> > Having introduced per-context seqno, we now have a means to identity
> > progress across the system without feel of rollback as befell the
> > global_seqno. That is we can program a MI_SEMAPHORE_WAIT oper
Quoting Chris Wilson (2019-01-31 13:39:50)
> Quoting Tvrtko Ursulin (2019-01-31 13:19:31)
> >
> > On 30/01/2019 02:19, Chris Wilson wrote:
> > > Having introduced per-context seqno, we now have a means to identity
> > > progress across the system without feel of rollback as befell the
> > > global
Include whether the scheduler is using HW semaphore assistance in our
pretty debug strings, and make the caps known for requires.
Signed-off-by: Chris Wilson
---
lib/i915/gem_scheduler.c | 22 +++---
lib/i915/gem_scheduler.h | 2 ++
2 files changed, 21 insertions(+), 3 deletions
How much energy does spinning on a semaphore consume relative to plain
old spinning?
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 72 +-
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/g
Read the RAPL power metrics courtesy of perf. Or your local HW
equivalent?
Signed-off-by: Chris Wilson
---
lib/Makefile.sources | 2 +
lib/igt_gpu_power.c | 106 +++
lib/igt_gpu_power.h | 51 +
lib/meson.build | 2 +
4 files
== Series Details ==
Series: drm: prefix header search paths with $(srctree)/
URL : https://patchwork.freedesktop.org/series/56020/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5516_full -> Patchwork_12100_full
Summary
---
On Mon, Jan 28, 2019 at 08:29:51PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/icl: Add TypeC ports only if VBT is present (rev2)
> URL : https://patchwork.freedesktop.org/series/55733/
> State : success
Pushed to -dinq, thanks for the review.
>
> == Summary ==
>
> CI
On Fri, Dec 21, 2018 at 04:02:07PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915/ddi: Move DDI port detection to
> the corresponding helper (rev2)
> URL : https://patchwork.freedesktop.org/series/54341/
> State : success
Pushed patch 3 too from
== Series Details ==
Series: drm/i915: do not return invalid pointers as a *dentry
URL : https://patchwork.freedesktop.org/series/56044/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12110
Summary
---
== Series Details ==
Series: series starting with drm/i915: Revoke mmaps and prevent access to fence
registers across reset (rev4)
URL : https://patchwork.freedesktop.org/series/56042/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12109
=
On 1/31/2019 1:26 PM, Daniel Vetter wrote:
On Thu, Jan 31, 2019 at 12:29:23PM +0530, Ramalingam C wrote:
"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status.
This SW tracking is used to determine the need for real hdcp1.4 disable
and hdcp_check_link upon CP_IRQ.
On CP_IRQ
On 1/31/2019 1:47 PM, Daniel Vetter wrote:
On Thu, Jan 31, 2019 at 12:29:22PM +0530, Ramalingam C wrote:
Defining the mei-i915 interface functions and initialization of
the interface.
v2:
Adjust to the new interface changes. [Tomas]
Added further debug logs for the failures at MEI i/f.
Quoting Tvrtko Ursulin (2019-01-31 13:19:31)
>
> On 30/01/2019 02:19, Chris Wilson wrote:
> > Having introduced per-context seqno, we now have a means to identity
> > progress across the system without feel of rollback as befell the
> > global_seqno. That is we can program a MI_SEMAPHORE_WAIT oper
Op 29-01-2019 om 15:22 schreef Hans de Goede:
> We really want to have fastboot enabled by default to avoid an ugly
> modeset during boot.
>
> Currently we are enabling fastboot by default on gen9+ (Skylake and newer).
> The intention is to enable it on older generations after it has seen more
> te
== Series Details ==
Series: series starting with drm/i915: Revoke mmaps and prevent access to fence
registers across reset (rev4)
URL : https://patchwork.freedesktop.org/series/56042/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Revoke mm
On 30/01/2019 02:19, Chris Wilson wrote:
Having introduced per-context seqno, we now have a means to identity
progress across the system without feel of rollback as befell the
global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in
advance of submission safe in the knowledge that o
When calling debugfs functions, they can now return error values if
something went wrong. If that happens, return a NULL as a *dentry to
the relay core instead of passing it an illegal pointer.
The relay core should be able to handle an illegal pointer, but add this
check to be safe.
Cc: Jani Ni
Previously, we were able to rely on the recursive properties of
struct_mutex to allow us to serialise revoking mmaps and reacquiring the
FENCE registers with them being clobbered over a global device reset.
I then proceeded to throw out the baby with the bath water in order to
pursue a struct_mutex
== Series Details ==
Series: series starting with [1/5] drm/i915: Revoke mmaps and prevent access to
fence registers across reset (rev3)
URL : https://patchwork.freedesktop.org/series/56042/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12108
===
On Thu, Jan 31, 2019 at 09:08:04AM +0100, Daniel Vetter wrote:
> On Thu, Jan 31, 2019 at 12:29:34PM +0530, Ramalingam C wrote:
> > Implements the
> > Waitqueue is created to wait for CP_IRQ
> > Signaling the CP_IRQ arrival through atomic variable.
> > For applicable DP HDCP2.2 msgs read
== Series Details ==
Series: drm/i915/psr: Execute the default PSR code path when setting
i915_edp_psr_debug (rev2)
URL : https://patchwork.freedesktop.org/series/56013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5515_full -> Patchwork_12099_full
==
== Series Details ==
Series: series starting with [1/5] drm/i915: Revoke mmaps and prevent access to
fence registers across reset (rev3)
URL : https://patchwork.freedesktop.org/series/56042/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Rev
== Series Details ==
Series: series starting with [1/5] drm/i915: Revoke mmaps and prevent access to
fence registers across reset
URL : https://patchwork.freedesktop.org/series/56042/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12107
==
== Series Details ==
Series: series starting with [1/5] drm/i915: Revoke mmaps and prevent access to
fence registers across reset
URL : https://patchwork.freedesktop.org/series/56042/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Revoke mma
Prevent concurrent set-wedge with ongoing resets (and vice versa) by
taking the same wedge_mutex around both operations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c | 68 ++-
1 file changed, 40 insertions(+), 28 deletions(-)
diff --git a/drivers
Prevent concurrent set-wedge with ongoing resets (and vice versa) by
taking the same wedge_mutex around both operations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c | 70 ++-
1 file changed, 40 insertions(+), 30 deletions(-)
diff --git a/drivers
On Wed, Jan 30, 2019 at 06:11:16PM -0800, Matt Roper wrote:
> On Wed, Jan 30, 2019 at 11:01:25PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 30, 2019 at 10:51:21AM -0800, Matt Roper wrote:
> > > Some display controllers can be programmed to present non-black colors
> > > for pixels not covered by a
Previously, we were able to rely on the recursive properties of
struct_mutex to allow us to serialise revoking mmaps and reacquiring the
FENCE registers with them being clobbered over a global device reset.
I then proceeded to throw out the baby with the bath water in order to
pursue a struct_mutex
When declaring the GPU wedged, we do need to hit the GPU with the reset
hammer so that its state matches our presumed state during cleanup. If
the reset fails, it fails, and we may be unhappy but wedged. However, if
we are testing our wedge/unwedged handling, the desync carries over into
the next t
Prevent concurrent set-wedge with ongoing resets (and vice versa) by
taking the same wedge_mutex around both operations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c | 71 ++-
1 file changed, 41 insertions(+), 30 deletions(-)
diff --git a/drivers
On wedging, we mark all executing requests as complete and all pending
requests completed as soon as they are ready. Before unwedging though we
wish to flush those pending requests prior to restoring default
execution, and so we must wait. Do so interruptibly as we do not provide
the EINTR graceful
Since we use the debugfs to recover the device after modifying the
i915.reset parameter, we need to be sure that we apply the reset and not
piggy-back onto a concurrent one in order for the parameter to take
effect.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 +++
On Tue, 29 Jan 2019, Jani Nikula wrote:
> This is obviously a backward/forward incompatible change. I've been
> told there are no systems out there using the field.
There are systems like that, in our CI too. Back to the drawing board.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Cent
Quoting Tvrtko Ursulin (2019-01-31 12:47:51)
> From: Tvrtko Ursulin
>
> We want to allow userspace to reconfigure the subslice configuration on a
> per context basis.
>
> This is required for the functional requirement of shutting down non-VME
> enabled sub-slices on Gen11 parts.
>
> To do so,
Quoting Tvrtko Ursulin (2019-01-31 11:39:46)
>
>
> On 30/01/2019 20:50, Chris Wilson wrote:
> > Wrap the active tracking for a GPU references in a slabcache for faster
> > allocations, and hopefully better fragmentation reduction.
> >
>
> v2 where art thou? :)
You killed v2!
> > v3: Nothing de
On 30/01/2019 20:50, Chris Wilson wrote:
Wrap the active tracking for a GPU references in a slabcache for faster
allocations, and hopefully better fragmentation reduction.
v2 where art thou? :)
v3: Nothing device specific left, it's just a slabcache that we can
make global.
Signed-off-by:
On 31/01/2019 11:32, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-31 11:25:10)
On 30/01/2019 20:50, Chris Wilson wrote:
We currently track GPU memory usage inside VMA, such that we never
release memory used by the GPU until after it has finished accessing it.
However, we may want to tr
On 30/01/2019 20:50, Chris Wilson wrote:
As soon as we detect that the active tracker is idle and we prepare to
call the retire callback, release the storage for our tree of
per-timeline nodes. We expect these to be infrequently usage and quick
s/usage/used/
to allocate, so there is little b
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev29)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5518 -> Patchwork_12106
Summary
---
Quoting Tvrtko Ursulin (2019-01-31 11:25:10)
>
> On 30/01/2019 20:50, Chris Wilson wrote:
> > We currently track GPU memory usage inside VMA, such that we never
> > release memory used by the GPU until after it has finished accessing it.
> > However, we may want to track other resources aside from
On 30/01/2019 20:50, Chris Wilson wrote:
We currently track GPU memory usage inside VMA, such that we never
release memory used by the GPU until after it has finished accessing it.
However, we may want to track other resources aside from VMA, or we may
want to split a VMA into multiple independe
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev29)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Record the sseu configuration per-context & engine
-drivers/
1 - 100 of 133 matches
Mail list logo
