Re: [Intel-gfx] [v8 2/2] drm/i915: Attach colorspace property and enable modeset

  Hello Ville, On 1/29/2019 9:33 PM, Ville Syrjälä wrote: On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ville Syrjälä Sent: Tuesday, January 29, 2019 9:14 PM To: Shankar, U

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2] i915/selftest: Allow filtering of individual subtests

Quoting Chris Wilson (2019-01-30 01:44:58) > Take an environment variable, SELFTESTS=foo,bar, and pass that along to > the kernel (as i915.st_filter=foo,bar) to provide fine grained test > selection. This can be either as an exact match to select only that > test, or to exclude only test. For examp

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/11] drm/i915: Revoke mmaps and prevent access to fence registers across reset

== Series Details == Series: series starting with [01/11] drm/i915: Revoke mmaps and prevent access to fence registers across reset URL : https://patchwork.freedesktop.org/series/55956/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5506_full -> Patchwork_12083_full ==

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Apply LUT validation checks to platforms more accurately (rev2)

== Series Details == Series: drm/i915: Apply LUT validation checks to platforms more accurately (rev2) URL : https://patchwork.freedesktop.org/series/55765/ State : success == Summary == CI Bug Log - changes from CI_DRM_5506_full -> Patchwork_12082_full ===

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm/i915: Revoke mmaps and prevent access to fence registers across reset

== Series Details == Series: series starting with [01/11] drm/i915: Revoke mmaps and prevent access to fence registers across reset URL : https://patchwork.freedesktop.org/series/55956/ State : success == Summary == CI Bug Log - changes from CI_DRM_5506 -> Patchwork_12083

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/11] drm/i915: Revoke mmaps and prevent access to fence registers across reset

== Series Details == Series: series starting with [01/11] drm/i915: Revoke mmaps and prevent access to fence registers across reset URL : https://patchwork.freedesktop.org/series/55956/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Revoke m

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915: Revoke mmaps and prevent access to fence registers across reset

== Series Details == Series: series starting with [01/11] drm/i915: Revoke mmaps and prevent access to fence registers across reset URL : https://patchwork.freedesktop.org/series/55956/ State : warning == Summary == $ dim checkpatch origin/drm-tip 45b1ecb63e1a drm/i915: Revoke mmaps and preve

[Intel-gfx] [PATCH 02/11] drm/i915/execlists: Suppress redundant preemption

On unwinding the active request we give it a small (limited to internal priority levels) boost to prevent it from being gazumped a second time. However, this means that it can be promoted to above the request that triggered the preemption request, causing a preempt-to-idle cycle for no change. We c

[Intel-gfx] [PATCH 01/11] drm/i915: Revoke mmaps and prevent access to fence registers across reset

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

[Intel-gfx] [PATCH 09/11] drm/i915/execlists: Refactor out can_merge_rq()

In the next patch, we add another user that wants to check whether requests can be merge into a single HW execution, and in the future we want to add more conditions under which requests from the same context cannot be merge. In preparation, extract out can_merge_rq(). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 10/11] drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+

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 our target seqno and address is stable. Howe

[Intel-gfx] [PATCH 08/11] drm/i915: Keep timeline HWSP allocated until the system is idle

In preparation for enabling HW semaphores, we need to keep in flight timeline HWSP alive until the entire system is idle, as any other timeline active on the GPU may still refer back to the already retired timeline. We both have to delay recycling available cachelines and unpinning old HWSP until t

[Intel-gfx] [PATCH 05/11] drm/i915: Add timeline barrier support

From: Tvrtko Ursulin Timeline barrier allows serialization between different timelines. After calling i915_timeline_set_barrier with a request, all following submissions on this timeline will be set up as depending on this request, or barrier. Once the barrier has been completed it automatically

[Intel-gfx] [PATCH 07/11] drm/i915: Pull i915_gem_active into the i915_active family

Looking forward, we need to break the struct_mutex dependency on i915_gem_active. In the meantime, external use of i915_gem_active is quite beguiling, little do new users suspect that it implies a barrier as each request it tracks must be ordered wrt the previous one. As one of many, it can be used

[Intel-gfx] [PATCH 03/11] drm/i915/selftests: Exercise some AB...BA preemption chains

Build a chain using 2 contexts (A, B) then request a preemption such that a later A request runs before the spinner in B. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/selftests/intel_lrc.c | 103 + 1 file changed, 103 insertions(+) diff -

[Intel-gfx] [PATCH 06/11] drm/i915: Allocate active tracking nodes from a slabcache

Wrap the active tracking for a GPU references in a slabcache for faster allocations, and keep track of inflight nodes so we can reap the stale entries upon parking (thereby trimming our memory usage). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_active.c| 55

[Intel-gfx] [PATCH 04/11] drm/i915: Generalise GPU activity tracking

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 independent regions and track each separately. For th

[Intel-gfx] [PATCH 11/11] drm/i915: Prioritise non-busywait semaphore workloads

We don't want to busywait on the GPU if we have other work to do. If we give non-busywaiting workloads higher (initial) priority than workloads that require a busywait, we will prioritise work that is ready to run immediately. Testcase: igt/gem_exec_schedule/semaphore Signed-off-by: Chris Wilson

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply LUT validation checks to platforms more accurately (rev2)

== Series Details == Series: drm/i915: Apply LUT validation checks to platforms more accurately (rev2) URL : https://patchwork.freedesktop.org/series/55765/ State : success == Summary == CI Bug Log - changes from CI_DRM_5506 -> Patchwork_12082 =

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Apply LUT validation checks to platforms more accurately (rev2)

== Series Details == Series: drm/i915: Apply LUT validation checks to platforms more accurately (rev2) URL : https://patchwork.freedesktop.org/series/55765/ State : warning == Summary == $ dim checkpatch origin/drm-tip b09041f843be drm/i915: Apply LUT validation checks to platforms more accur

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915: Remove the intel_engine_notify tracepoint

== Series Details == Series: series starting with [CI,1/3] drm/i915: Remove the intel_engine_notify tracepoint URL : https://patchwork.freedesktop.org/series/55939/ State : success == Summary == CI Bug Log - changes from CI_DRM_5503_full -> Patchwork_12081_full ===

[Intel-gfx] [PATCH] drm/i915: Apply LUT validation checks to platforms more accurately (v2)

Use of the new DRM_COLOR_LUT_NON_DECREASING test was a bit over-zealous; it doesn't actually need to be applied to the degamma on "bdw-style" platforms. Likewise, we overlooked the fact that CHV should have that test applied to the gamma LUT as well as the degamma LUT. Rather than adding more com

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Pass dev_priv to skl_needs_memory_bw_wa()

On Fri, Dec 21, 2018 at 07:14:33PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > skl_needs_memory_bw_wa() doesn't look at the passed in state at all. > Possibly it should, but for now let's make life simpler by just > passing in dev_priv. > > Signed-off-by: Ville Syrjälä Reviewed-by: M

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Use IS_GEN9_LP() for the linetime w/a check

On Fri, Dec 21, 2018 at 07:14:36PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > IS_GLK||IS_BXT == IS_GEN9_LP > > Signed-off-by: Ville Syrjälä Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/intel_pm.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Fix bits vs. bytes mixup in dbuf block size computation

On Fri, Dec 21, 2018 at 07:14:30PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > The spec used to say "8bpp" which someone took to mean 8 bytes per > pixel when in fact it was supposed to be 8 bits per pixel. The > spec has been updated to make it more clear now. Fix the code > to match.

Re: [Intel-gfx] [PATCH 4/9] drm/i915: Fix > vs >= mismatch in watermark/ddb calculations

On Fri, Dec 21, 2018 at 07:14:31PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Bspec says we have to reject the watermark if it's >= the ddb > allocation. Fix the code to reject the == case as it should. > For transition watermarks we can just use >=, for the rest > we'll do +1 when cal

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Drop the pointless linetime==0 check

On Fri, Dec 21, 2018 at 07:14:35PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > 0*whatever==0 so this check is pointless. Remove it. > > Signed-off-by: Ville Syrjälä Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/intel_pm.c | 4 > 1 file changed, 4 deletions(-) > > diff

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Reinstate an early latency==0 check for skl+

On Fri, Dec 21, 2018 at 07:14:29PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > I thought we could remove all the early latency==0 checks > and rely on skl_wm_method{1,2}() checking for it. But > skl_compute_plane_wm() applies a bunch of workarounds to bump > up the latency before callin

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Account for minimum ddb allocation restrictions

On Fri, Dec 21, 2018 at 07:14:32PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > On icl+ bspec tells us to calculate a separate minimum ddb > allocation from the blocks watermark. Both have to be checked > against the actual ddb allocation, but since we do things the > other way around we

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Don't ignore level 0 lines watermark for glk+

On Fri, Dec 21, 2018 at 07:14:28PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > On glk+ the level 0 lines watermark actually matters. Do not ignore it. > And while at it let's change things so that we always program a > consistnet 0 to the register when the lines watermarks is ignored >

[Intel-gfx] [PATCH i-g-t v2] i915/selftest: Allow filtering of individual subtests

Take an environment variable, SELFTESTS=foo,bar, and pass that along to the kernel (as i915.st_filter=foo,bar) to provide fine grained test selection. This can be either as an exact match to select only that test, or to exclude only test. For example, SELFTESTS=igt_vma_create,igt_vma_pin1 i915_sel

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_eio: Check for allow-hang prior to issuing a reset

Quoting Antonio Argenziano (2019-01-29 23:36:38) > > > On 27/01/19 04:49, Chris Wilson wrote: > > Check that we are allowed to hang/reset the GPU before we actually do so > > for the first time. > > > > Signed-off-by: Chris Wilson > > --- > > tests/i915/gem_eio.c | 8 > > 1 file cha

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_capture: Check the strlen() for an empty file

On 29/01/19 03:24, Chris Wilson wrote: igt_sysfs_get() only returns NULL if the open() fails, and a valid string otherwise. So if the read() fails with ENODEV (because sysfs doesn't provide the driver with an ->open() callback), we return an empty string, and "No error captured" otherwise. Bug

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_eio: Check for allow-hang prior to issuing a reset

On 27/01/19 04:49, Chris Wilson wrote: Check that we are allowed to hang/reset the GPU before we actually do so for the first time. Signed-off-by: Chris Wilson --- tests/i915/gem_eio.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/i915/gem_eio.c b/tests/

Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

On Tue, Jan 29, 2019 at 2:39 PM Stephen Rothwell wrote: > > Hi all, > > After merging the drm-intel-fixes tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/gpu/drm/i915/intel_display.c: In function 'has_bogus_dpll_config': > drivers/gpu/drm/i915/intel_display.c:1

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: MST and wakeref leak fixes (rev2)

== Series Details == Series: drm/i915: MST and wakeref leak fixes (rev2) URL : https://patchwork.freedesktop.org/series/55868/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501_full -> Patchwork_12080_full Summary ---

[Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

Hi all, After merging the drm-intel-fixes tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/i915/intel_display.c: In function 'has_bogus_dpll_config': drivers/gpu/drm/i915/intel_display.c:15432:27: error: macro "IS_GEN" requires 3 arguments, but only 2 given

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp_mst: Fix regressions from new atomic VCPI helpers

== Series Details == Series: drm/dp_mst: Fix regressions from new atomic VCPI helpers URL : https://patchwork.freedesktop.org/series/55933/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501_full -> Patchwork_12078_full Sum

Re: [Intel-gfx] [PATCH] drm: Constify drm_color_lut_check()

On Tue, Jan 29, 2019 at 08:04:18PM +0100, Daniel Vetter wrote: > On Tue, Jan 29, 2019 at 07:58:56PM +0200, Ville Syrjälä wrote: > > On Tue, Jan 29, 2019 at 06:52:51PM +0100, Sam Ravnborg wrote: > > > Hi Ville. > > > > > > On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote: > > > > From:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Remove the intel_engine_notify tracepoint

== Series Details == Series: series starting with [CI,1/3] drm/i915: Remove the intel_engine_notify tracepoint URL : https://patchwork.freedesktop.org/series/55939/ State : success == Summary == CI Bug Log - changes from CI_DRM_5503 -> Patchwork_12081 =

[Intel-gfx] ✓ Fi.CI.IGT: success for Add Colorspace connector property interface (rev9)

== Series Details == Series: Add Colorspace connector property interface (rev9) URL : https://patchwork.freedesktop.org/series/47132/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501_full -> Patchwork_12077_full Summary -

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/3] drm/i915: Remove the intel_engine_notify tracepoint

== Series Details == Series: series starting with [CI,1/3] drm/i915: Remove the intel_engine_notify tracepoint URL : https://patchwork.freedesktop.org/series/55939/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Remove the intel_engine_notif

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/3] drm/i915: Remove the intel_engine_notify tracepoint

== Series Details == Series: series starting with [CI,1/3] drm/i915: Remove the intel_engine_notify tracepoint URL : https://patchwork.freedesktop.org/series/55939/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8f31dfb2f578 drm/i915: Remove the intel_engine_notify tracepoint 0

[Intel-gfx] [CI 2/3] drm/i915: Replace global breadcrumbs with per-context interrupt tracking

A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the thundering i915_wait_request herd"), the issue of handling multiple clients waiting in parallel was brought to our attention. The requirement was that every client should be woken immediately upon its request being signaled, without

[Intel-gfx] [CI 1/3] drm/i915: Remove the intel_engine_notify tracepoint

The global seqno is defunct and so we have no meaningful indicator of forward progress for an engine. You need to listen to the request signaling tracepoints instead. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_irq.c | 2 -- drivers/gpu/drm/i915/i915

[Intel-gfx] [CI 3/3] drm/i915: Drop fake breadcrumb irq

Missed breadcrumb detection is defunct due to the tight coupling with dma_fence signaling and the myriad ways we may signal fences from everywhere but from an interrupt, i.e. we frequently signal a fence before we even see its interrupt. This means that even if we miss an interrupt for a fence, it

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Constify drm_color_lut_check()

== Series Details == Series: drm: Constify drm_color_lut_check() URL : https://patchwork.freedesktop.org/series/55924/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501_full -> Patchwork_12076_full Summary --- **SUC

Re: [Intel-gfx] [PATCH 1/3] drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

On Tue, Jan 29, 2019 at 01:39:25PM -0500, Lyude Paul wrote: > In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call > drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we > never successfully allocated VCPI to it. This is contrary to what we do > in drm_dp_mst_alloc

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Always allocate VCPI during system resume

On Tue, Jan 29, 2019 at 01:39:27PM -0500, Lyude Paul wrote: > Since there's a chance MST topologies can be removed while the system is > in suspend, there's also a chance that the connectors in the atomic > state which we try to restore on system resume will have been > unregistered if they were pa

Re: [Intel-gfx] [PATCH 2/3] drm/atomic: Add drm_atomic_state->suspend_or_resume

On Tue, Jan 29, 2019 at 01:39:26PM -0500, Lyude Paul wrote: > Since > > commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered > connectors harder") > > We've been failing atomic checks if they try to enable new displays on > unregistered connectors. This is fine except for the on

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: MST and wakeref leak fixes (rev2)

== Series Details == Series: drm/i915: MST and wakeref leak fixes (rev2) URL : https://patchwork.freedesktop.org/series/55868/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501 -> Patchwork_12080 Summary --- **SUCCE

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set

== Series Details == Series: series starting with [v2,1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set URL : https://patchwork.freedesktop.org/series/55919/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501_full -> Patchwork_12074_full ===

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Enable fastboot by default on VLV and CHV

== Series Details == Series: drm/i915: Enable fastboot by default on VLV and CHV URL : https://patchwork.freedesktop.org/series/55911/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501_full -> Patchwork_12071_full Summary

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: MST and wakeref leak fixes (rev2)

== Series Details == Series: drm/i915: MST and wakeref leak fixes (rev2) URL : https://patchwork.freedesktop.org/series/55868/ State : warning == Summary == $ dim checkpatch origin/drm-tip 13be9527c910 drm/i915: Block fbdev HPD processing during suspend -:77: WARNING:BOOL_BITFIELD: Avoid using

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/4] drm/i915/selftests: Apply a subtest filter

== Series Details == Series: series starting with [CI,1/4] drm/i915/selftests: Apply a subtest filter URL : https://patchwork.freedesktop.org/series/55934/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5501 -> Patchwork_12079 ===

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/4] drm/i915/selftests: Apply a subtest filter

== Series Details == Series: series starting with [CI,1/4] drm/i915/selftests: Apply a subtest filter URL : https://patchwork.freedesktop.org/series/55934/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/selftests: Apply a subtest filter Okay!

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915/selftests: Apply a subtest filter

== Series Details == Series: series starting with [CI,1/4] drm/i915/selftests: Apply a subtest filter URL : https://patchwork.freedesktop.org/series/55934/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0d88b17969c3 drm/i915/selftests: Apply a subtest filter aea480e69b0b drm/i91

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp_mst: Fix regressions from new atomic VCPI helpers

== Series Details == Series: drm/dp_mst: Fix regressions from new atomic VCPI helpers URL : https://patchwork.freedesktop.org/series/55933/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501 -> Patchwork_12078 Summary -

Re: [Intel-gfx] [PATCH] drm: Constify drm_color_lut_check()

On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > drm_color_lut_check() doens't modify the passed in blob so s/doens't/doesn't/ Otherwise, LGTM. Reviewed-by: > let's make it const. > > Also s/uint32_y/u32/ while at it. > > Cc: Matt Roper > Signed-off

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: Block fbdev HPD processing during suspend

Quoting Lyude Paul (2019-01-29 19:09:59) > When resuming, we check whether or not any previously connected > MST topologies are still present and if so, attempt to resume them. If > this fails, we disable said MST topologies and fire off a hotplug event > so that userspace knows to reprobe. > > Ho

[Intel-gfx] ✓ Fi.CI.BAT: success for Add Colorspace connector property interface (rev9)

== Series Details == Series: Add Colorspace connector property interface (rev9) URL : https://patchwork.freedesktop.org/series/47132/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501 -> Patchwork_12077 Summary ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp_mst: Fix regressions from new atomic VCPI helpers

== Series Details == Series: drm/dp_mst: Fix regressions from new atomic VCPI helpers URL : https://patchwork.freedesktop.org/series/55933/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5eace8601b7f drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi() e8ee56a0

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/tv: Fix adjusted_mode dotclock for interlaced modes

== Series Details == Series: series starting with [1/2] drm/i915/tv: Fix adjusted_mode dotclock for interlaced modes URL : https://patchwork.freedesktop.org/series/55909/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501_full -> Patchwork_12070_full =

[Intel-gfx] [PATCH v3 2/3] drm/i915: Don't send MST hotplugs during resume

We have a bad habit of calling drm_fb_helper_hotplug_event() far more then we actually need to. MST appears to be one of these cases, where we call drm_fb_helper_hotplug_event() if we fail to resume a connected MST topology in intel_dp_mst_resume(). We don't actually need to do this at all though s

[Intel-gfx] [PATCH v3 1/3] drm/i915: Block fbdev HPD processing during suspend

When resuming, we check whether or not any previously connected MST topologies are still present and if so, attempt to resume them. If this fails, we disable said MST topologies and fire off a hotplug event so that userspace knows to reprobe. However, sending a hotplug event involves calling drm_f

[Intel-gfx] [PATCH v3 3/3] drm/i915: Don't send hotplug in intel_dp_check_mst_status()

This hotplug also isn't needed: drm_dp_mst_topology_mgr_set_mst() already sends a hotplug on its own from drm_dp_destroy_connector_work() after destroying connectors in the MST topology. Signed-off-by: Lyude Paul Cc: Imre Deak Cc: Daniel Vetter --- drivers/gpu/drm/i915/intel_dp.c | 6 ++ 1

[Intel-gfx] [PATCH v3 0/3] drm/i915: MST and wakeref leak fixes

While trying to fix a problem with suspend/resume that I introduced in the atomic VCPI helpers for MST, I also ran into some issues with i915 varying from "not that bad" to "oh wow that's very bad". Here are the fixes for those issues. This series was originally just one patch, "drm/i915: Don't se

Re: [Intel-gfx] [PATCH] drm: Constify drm_color_lut_check()

On Tue, Jan 29, 2019 at 07:58:56PM +0200, Ville Syrjälä wrote: > On Tue, Jan 29, 2019 at 06:52:51PM +0100, Sam Ravnborg wrote: > > Hi Ville. > > > > On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > drm_color_lut_check() doens't modify the passe

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_workarounds: Require GPU resets

Quoting Tvrtko Ursulin (2019-01-28 13:47:02) > > On 28/01/2019 11:23, Chris Wilson wrote: > > Check that we are allowed to reset the GPU prior to execution. > > > > v2: Push the require checking up into a subgroup > > > > Signed-off-by: Chris Wilson > > --- > > tests/i915/gem_workarounds.c |

[Intel-gfx] [CI 2/4] drm/i915: Identify active requests

To allow requests to forgo a common execution timeline, one question we need to be able to answer is "is this request running?". To track whether a request has started on HW, we can emit a breadcrumb at the beginning of the request and check its timeline's HWSP to see if the breadcrumb has advanced

[Intel-gfx] [CI 3/4] drm/i915: Rename execlists->queue_priority to queue_priority_hint

After noticing that we trigger preemption events for currently executing requests, as well as requests that complete before the preemption and attempting to suppress those preemption events, it is wise to not consider the queue_priority to be authoritative. As we only track the maximum priority see

[Intel-gfx] [CI 1/4] drm/i915/selftests: Apply a subtest filter

In bringup on simulated HW even rudimentary tests are slow, and so many may fail that we want to be able to filter out the noise to focus on the specific problem. Even just the tests groups provided for igt is not specific enough, and we would like to isolate one particular subtest (and probably su

[Intel-gfx] [CI 4/4] drm/i915/execlists: Suppress preempting self

In order to avoid preempting ourselves, we currently refuse to schedule the tasklet if we reschedule an inflight context. However, this glosses over a few issues such as what happens after a CS completion event and we then preempt the newly executing context with itself, or if something else causes

Re: [Intel-gfx] [PATCH] drm/i915: Don't send MST hotplugs until after resume

Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 0e32b39ceed6 drm/i915: add DP 1.2 MST support (v0.7). The bot has tested the following trees: v4.20.5, v4.19.18, v4.14.96, v4.9.153, v4.4.172, v3.18.133. v4.20.5: Build OK! v4.19.

Re: [Intel-gfx] [PATCH 0/3] gcc-plugins: Introduce stackinit plugin

On 23.01.2019 14:03, Kees Cook wrote: > This adds a new plugin "stackinit" that attempts to perform unconditional > initialization of all stack variables Hello Kees! Hello everyone! I was curious about the performance impact of the initialization of all stack variables. So I did a very brief test

Re: [Intel-gfx] [PATCH] drm/i915: Don't send MST hotplugs until after resume

Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 0e32b39ceed6 drm/i915: add DP 1.2 MST support (v0.7). The bot has tested the following trees: v4.20.5, v4.19.18, v4.14.96, v4.9.153, v4.4.172, v3.18.133. v4.20.5: Build OK! v4.19.

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add Colorspace connector property interface (rev9)

== Series Details == Series: Add Colorspace connector property interface (rev9) URL : https://patchwork.freedesktop.org/series/47132/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm: Add HDMI colorspace property + ~~~^~~

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add Colorspace connector property interface (rev9)

== Series Details == Series: Add Colorspace connector property interface (rev9) URL : https://patchwork.freedesktop.org/series/47132/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2966dae600a0 drm: Add HDMI colorspace property -:159: CHECK:PARENTHESIS_ALIGNMENT: Alignment shoul

[Intel-gfx] [PATCH 3/3] drm/i915: Always allocate VCPI during system resume

Since there's a chance MST topologies can be removed while the system is in suspend, there's also a chance that the connectors in the atomic state which we try to restore on system resume will have been unregistered if they were part of an MST topology that was removed mid-suspend. In such situatio

[Intel-gfx] [PATCH 0/3] drm/dp_mst: Fix regressions from new atomic VCPI helpers

This fixes the extra issues I discovered upstream after the introduction of my rework of the atomic VCPI helpers that occur during suspend/resume. Lyude Paul (3): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi() drm/atomic: Add drm_atomic_state->suspend_or_resume drm/i91

[Intel-gfx] [PATCH 2/3] drm/atomic: Add drm_atomic_state->suspend_or_resume

Since commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered connectors harder") We've been failing atomic checks if they try to enable new displays on unregistered connectors. This is fine except for the one situation that breaks atomic assumptions: suspend/resume. If a connector

[Intel-gfx] [PATCH 1/3] drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we never successfully allocated VCPI to it. This is contrary to what we do in drm_dp_mst_allocate_vcpi(), where we only call drm_dp_mst_get_port_malloc() on the p

[Intel-gfx] [v9 0/3] Add Colorspace connector property interface

This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scen

[Intel-gfx] [v9 2/3] drm: Add DP colorspace property

This patch adds a DP colorspace property, enabling userspace to switch to various supported colorspaces. This will help enable BT2020 along with other colorspaces. v2: Addressed Maarten and Ville's review comments. Enhanced the colorspace enum to incorporate both HDMI and DP supported colo

[Intel-gfx] [v9 3/3] drm/i915: Attach colorspace property and enable modeset

This patch attaches the colorspace connector property to the hdmi connector. Based on colorspace change, modeset will be triggered to switch to new colorspace. Based on colorspace property value create an infoframe with appropriate colorspace. This can be used to send an infoframe packet with prop

[Intel-gfx] [v9 1/3] drm: Add HDMI colorspace property

Create a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Constify drm_color_lut_check()

== Series Details == Series: drm: Constify drm_color_lut_check() URL : https://patchwork.freedesktop.org/series/55924/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501 -> Patchwork_12076 Summary --- **SUCCESS**

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] i915/gem_exec_latency: Normalize results into ns

Quoting Antonio Argenziano (2019-01-29 17:55:45) > > > On 29/01/19 01:55, Chris Wilson wrote: > > Present the latency results in nanoseconds not RCS cycles. > > > > Signed-off-by: Chris Wilson > > --- > > tests/i915/gem_exec_latency.c | 38 +++ > > 1 file chan

Re: [Intel-gfx] [PATCH] drm: Constify drm_color_lut_check()

On Tue, Jan 29, 2019 at 06:52:51PM +0100, Sam Ravnborg wrote: > Hi Ville. > > On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > drm_color_lut_check() doens't modify the passed in blob so > > let's make it const. > > > > Also s/uint32_y/u32/ while at

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] i915/gem_exec_latency: Normalize results into ns

On 29/01/19 01:55, Chris Wilson wrote: Present the latency results in nanoseconds not RCS cycles. Signed-off-by: Chris Wilson --- tests/i915/gem_exec_latency.c | 38 +++ 1 file changed, 34 insertions(+), 4 deletions(-) diff --git a/tests/i915/gem_exec_laten

Re: [Intel-gfx] [PATCH] drm: Constify drm_color_lut_check()

Hi Ville. On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > drm_color_lut_check() doens't modify the passed in blob so > let's make it const. > > Also s/uint32_y/u32/ while at it. > > Cc: Matt Roper > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/dr

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/9] drm/i915/selftests: Apply a subtest filter

== Series Details == Series: series starting with [1/9] drm/i915/selftests: Apply a subtest filter URL : https://patchwork.freedesktop.org/series/55923/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5501 -> Patchwork_12075

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/9] drm/i915/selftests: Apply a subtest filter

== Series Details == Series: series starting with [1/9] drm/i915/selftests: Apply a subtest filter URL : https://patchwork.freedesktop.org/series/55923/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/selftests: Apply a subtest filter Okay! Co

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915/selftests: Apply a subtest filter

== Series Details == Series: series starting with [1/9] drm/i915/selftests: Apply a subtest filter URL : https://patchwork.freedesktop.org/series/55923/ State : warning == Summary == $ dim checkpatch origin/drm-tip f2bdc9bb090c drm/i915/selftests: Apply a subtest filter 6d8ec8621635 drm/i915:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set

== Series Details == Series: series starting with [v2,1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set URL : https://patchwork.freedesktop.org/series/55919/ State : success == Summary == CI Bug Log - changes from CI_DRM_5501 -> Patchwork_12074 =

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/pm_rpm: Check for functional GEM before use

On 27/01/19 05:13, Chris Wilson wrote: Check the GPU (using GEM) is up an operational before submitting commands. Always a good idea. Reviewed-by: Antonio Argenziano Signed-off-by: Chris Wilson --- tests/pm_rpm.c | 4 1 file changed, 4 insertions(+) diff --git a/tests/pm_rpm.c b

Re: [Intel-gfx] [PATCH 5/9] drm/i915/selftests: Exercise some AB...BA preemption chains

Quoting Chris Wilson (2019-01-29 17:02:03) > Build a chain using 2 contexts (A, B) then request a preemption such > that a later A request runs before the spinner in B. > > Signed-off-by: Chris Wilson Already, Reviewed-by: Tvrtko Ursulin -Chris ___ Int

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Rename execlists->queue_priority to queue_priority_hint

Quoting Chris Wilson (2019-01-29 17:02:00) > After noticing that we trigger preemption events for currently executing > requests, as well as requests that complete before the preemption and > attempting to suppress those preemption events, it is wise to not > consider the queue_priority to be autho

[Intel-gfx] [PATCH] drm: Constify drm_color_lut_check()

From: Ville Syrjälä drm_color_lut_check() doens't modify the passed in blob so let's make it const. Also s/uint32_y/u32/ while at it. Cc: Matt Roper Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_color_mgmt.c | 6 +++--- include/drm/drm_color_mgmt.h | 4 ++-- 2 files changed, 5 ins

[Intel-gfx] [PATCH 6/9] drm/i915: Identify active requests

To allow requests to forgo a common execution timeline, one question we need to be able to answer is "is this request running?". To track whether a request has started on HW, we can emit a breadcrumb at the beginning of the request and check its timeline's HWSP to see if the breadcrumb has advanced

  1   2   3   >