[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

== Series Details == Series: series starting with [1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display URL : https://patchwork.freedesktop.org/series/38410/ State : success == Summary == Series 38410v1 series starting with [1/5] drm/i915/frontbuffer: Pull

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

== Series Details == Series: series starting with [1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display URL : https://patchwork.freedesktop.org/series/38410/ State : warning == Summary == $ dim checkpatch origin/drm-tip 28b7f4f93d2f drm/i915/frontbuffer: Pull

[Intel-gfx] [PATCH 2/5] drm/i915/psr: Use more PSR HW tracking.

From: Rodrigo Vivi So far we are using frontbuffer tracking for everything and ignoring that PSR has a HW capable HW tracking for many modern usages of GPU on Core platforms and newer Atom ones. One reason for that is that we were trying to keep same infrastructure in

[Intel-gfx] [PATCH 1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to DIRTYFB. The callers however are at a vantage point to decide if hardware frontbuffer tracking can do the flush for us. For example, legacy cursor updates, like flips, write to MMIO registers, which then triggers PSR flush by

[Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

Preparing a framebuffer should not require a flush. _post_plane_update() takes care of flushing when a flip is scheduled, this should be sufficient for PSR and FBC. Cc: Paulo Zanoni Cc: Ville Syrjälä Cc: Chris Wilson

[Intel-gfx] [PATCH 5/5] drm/i915/psr: Wait for PSR transition to complete before exiting.

With fbdev, screen freezes after a few continuous PSR exit->enter cycles. Printing out the PSR status register clearly showed this freeze coincided with exiting when the hardware is in a transitory state. So wait for a max of 100 ms (~6 frames) for PSR to become active and then exit. Cc: Rodrigo

[Intel-gfx] [PATCH 3/5] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor plane MMIOs are written to. But this flush should not be necessary for PSR as hardware tracking triggers PSR exit when MMIOs are written. As for FBC, the spec says "Flips or changes to plane size and panning" cause FBC to be

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

== Series Details == Series: series starting with [CI,1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display URL : https://patchwork.freedesktop.org/series/38408/ State : success == Summary == Series 38408v1 series starting with [CI,1/5] drm/i915/frontbuffer: Pull

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

== Series Details == Series: series starting with [CI,1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display URL : https://patchwork.freedesktop.org/series/38408/ State : warning == Summary == $ dim checkpatch origin/drm-tip 96ba61282f3d drm/i915/frontbuffer: Pull

[Intel-gfx] [CI 5/5] drm/i915/psr: Wait for PSR transition to complete before exiting.

With fbdev, screen freezes after a few continuous PSR exit->enter cycles. Printing out the PSR status register clearly showed this freeze coincided with exiting when the hardware is in a transitory state. So wait for a max of 100 ms (~6 frames) for PSR to become active and then exit. Cc: Rodrigo

[Intel-gfx] [CI 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

Preparing a framebuffer should not require a flush. _post_plane_update() takes care of flushing when a flip is scheduled, this should be sufficient for PSR and FBC. Cc: Paulo Zanoni Cc: Ville Syrjälä Cc: Chris Wilson

[Intel-gfx] [CI 3/5] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor plane MMIOs are written to. But this flush should not be necessary for PSR as hardware tracking triggers PSR exit when MMIOs are written. As for FBC, the spec says "Flips or changes to plane size and panning" cause FBC to be

[Intel-gfx] [CI 2/5] drm/i915/psr: Use more PSR HW tracking.

From: Rodrigo Vivi So far we are using frontbuffer tracking for everything and ignoring that PSR has a HW capable HW tracking for many modern usages of GPU on Core platforms and newer Atom ones. One reason for that is that we were trying to keep same infrastructure in

[Intel-gfx] [CI 1/5] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to DIRTYFB. The callers however are at a vantage point to decide if hardware frontbuffer tracking can do the flush for us. For example, legacy cursor updates, like flips, write to MMIO registers, which then triggers PSR flush by

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Assert that we always complete a submission to guc/execlists

== Series Details == Series: drm/i915: Assert that we always complete a submission to guc/execlists URL : https://patchwork.freedesktop.org/series/38376/ State : warning == Summary == Test kms_flip: Subgroup modeset-vs-vblank-race: pass -> FAIL (shard-hsw)

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use seqlock in engine stats (rev2)

== Series Details == Series: drm/i915: Use seqlock in engine stats (rev2) URL : https://patchwork.freedesktop.org/series/38347/ State : failure == Summary == Test perf_pmu: Subgroup busy-start-vcs0: pass -> DMESG-WARN (shard-apl) Subgroup

Re: [Intel-gfx] [PATCH 1/3] drm/i915/cnl: Fix PORT_TX_DW5/7 register address

On Thu, Feb 15, 2018 at 04:02:46PM +0200, Jani Nikula wrote: > On Thu, 15 Feb 2018, Mahesh Kumar wrote: > > Register Address for CNL_PORT_DW5_LN0_D is 0x162E54, but current code is > > defining it as 0x162ED4. Similarly for CNL_PORT_DW7_LN0_D register address > > is

Re: [Intel-gfx] [PATCH] drm/i915: Release connector iterator on a digital port conflict.

On Thu, Feb 15, 2018 at 10:14:25AM +0100, Maarten Lankhorst wrote: > <4>[ 30.702366] > <4>[ 30.702383] WARNING: lock held when returning to user space! > <4>[ 30.702404] 4.16.0-rc1-CI-kasan_1+ #1 Tainted: GW > <4>[ 30.702422]

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Move a bunch of workaround-related code to its own file

== Series Details == Series: series starting with [1/6] drm/i915: Move a bunch of workaround-related code to its own file URL : https://patchwork.freedesktop.org/series/38397/ State : success == Summary == Series 38397v1 series starting with [1/6] drm/i915: Move a bunch of

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915: Move a bunch of workaround-related code to its own file

== Series Details == Series: series starting with [1/6] drm/i915: Move a bunch of workaround-related code to its own file URL : https://patchwork.freedesktop.org/series/38397/ State : warning == Summary == $ dim checkpatch origin/drm-tip 349d068aa6d4 drm/i915: Move a bunch of

[Intel-gfx] [PATCH 3/6] drm/i915: Apply context workarounds directly

Once upon a time, we tried to apply workarounds for registers that lived inside the context image for every new context. That meant emitting LRI commands soon after each context was created. Nowadays, we have a single golden context that gets used as a master template for future contexts. That

[Intel-gfx] [PATCH 5/6] drm/i915: Create a new category of display WAs

Display workarounds do not need to be re-applied on a GPU reset (this is, in Ville's words: "at the very least wasted effort [...] and could even be actively harmful in case we end up clobbering something the current display configuration depends on"). Therefore, they have to be applied in a

[Intel-gfx] [PATCH 1/6] drm/i915: Move a bunch of workaround-related code to its own file

This has grown to be a sizable amount of code, so move it to its own file before we try to refactor anything. For the moment, we are leaving behind the WA BB code and the WAs that get applied (incorrectly) in init_clock_gating, but we will deal with it later. v2: Use intel_ prefix for code that

[Intel-gfx] [PATCH 6/6] drm/i915: Classify GT & Display WAs correctly

Move GT WAs appropiately from the current xxx_disp_workarounds_apply function to the corresponding xxx_gt_workarounds_apply one. FIXME: It looks like Chris has found some WAs that actually live in the context image. We need to move these to their rightful xxx_workarounds_init function. v2:

[Intel-gfx] [PATCH 2/6] drm/i915: Split out functions for different kinds of workarounds

There are different kind of workarounds (those that modify registers that live in the context image, those that modify global registers, those that whitelist registers, etc...) and they have different requirements in terms of where they are applied and how. Also, by splitting them apart, it should

[Intel-gfx] [PATCH 4/6] drm/i915: Move WA BB stuff to the workarounds file as well

Since we are trying to put all WA stuff together, do not forget about the BB WAs. v2: s/intel_bb_workarounds_init/intel_engine_init_bb_workarounds (Chris) v3: Rebased to before the WAs are stored v4: Rebased Reviewed-by: Chris Wilson (v2) Signed-off-by: Oscar Mateo

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

Dave Airlie writes: > On 6 February 2018 at 06:32, Rodrigo Vivi wrote: >> On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote: >>> Dhinakaran Pandiyan writes: >>> >>> > From: "Pandiyan, Dhinakaran"

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: expose RCS topology to userspace

== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/38356/ State : failure == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-pri-indfb-multidraw: pass -> FAIL (shard-snb)

Re: [Intel-gfx] [PATCH] drm/i915: Fix Limited Range Color Handling

>> >> >> >-Original Message- >> >> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >> >> >> >Sent: Friday, December 22, 2017 9:43 PM >> >> >> >To: Shankar, Uma >> >> >> >Cc: intel-gfx@lists.freedesktop.org; Lin, Johnson >> >> >>

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gtt: Convert WARN_ON to GEM debugging

== Series Details == Series: drm/i915/gtt: Convert WARN_ON to GEM debugging URL : https://patchwork.freedesktop.org/series/38346/ State : success == Summary == Test pm_rpm: Subgroup system-suspend-execbuf: pass -> DMESG-WARN (shard-apl) fdo#103375 +1 Test

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/mm: Fix caching of leftmost node in the interval tree

== Series Details == Series: drm/mm: Fix caching of leftmost node in the interval tree URL : https://patchwork.freedesktop.org/series/38351/ State : success == Summary == Test perf: Subgroup enable-disable: fail -> PASS (shard-apl) fdo#103715

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Track GT interrupt handling using the master iir

On Thu, Feb 15, 2018 at 04:00:04PM +, Chris Wilson wrote: > Quoting Mika Kuoppala (2018-02-15 15:21:33) > > Chris Wilson writes: > > > > > Keep the master iir and use it to reduce the number of reads and writes > > > to the GT iir array, i.e. only the bits marked as

Re: [Intel-gfx] [PATCH 05/19] drm/i915/icl: Interrupt handling

+ +static void +gen11_gt_irq_handler(struct drm_i915_private * const i915, +const u32 master_ctl) +{ + void __iomem * const regs = i915->regs; + unsigned int bank; + + for (bank = 0; bank < 2; bank++) { + unsigned long intr_dw; +

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Prune gen8_gt_irq_handler

Chris Wilson writes: > Quoting Chris Wilson (2018-02-15 07:37:13) >> if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) { >> - gt_iir[0] = I915_READ_FW(GEN8_GT_IIR(0)); >> - if (gt_iir[0]) >> -

Re: [Intel-gfx] [PATCH] drm/i915/gtt: Convert WARN_ON to GEM debugging

Quoting Matthew Auld (2018-02-15 14:09:45) > On 15 February 2018 at 11:07, Chris Wilson wrote: > > As we presume that we have sufficient coverage of CI for new machines > > and new code paths, we do not need to have user impacting WARN_ON for > > programming errors

Re: [Intel-gfx] [PATCH v3] drm/i915: Clean up ancient doc comments for i915_ioc32.c

Quoting Jani Nikula (2018-02-15 14:00:34) > On Thu, 15 Feb 2018, Chris Wilson wrote: > > Quoting Chris Wilson (2018-02-14 16:07:20) > >> As befitting a file dedicated to the mistakes of the past, > >> > >> drivers/gpu/drm/i915/i915_ioc32.c:2: warning: Cannot understand

[Intel-gfx] ✗ Fi.CI.BAT: failure for ICL GEM enabling (v2) (rev5)

== Series Details == Series: ICL GEM enabling (v2) (rev5) URL : https://patchwork.freedesktop.org/series/38174/ State : failure == Summary == Applying: drm/i915/icl: Add the ICL PCI IDs Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_pci.c M

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Assert that we always complete a submission to guc/execlists

== Series Details == Series: drm/i915: Assert that we always complete a submission to guc/execlists URL : https://patchwork.freedesktop.org/series/38376/ State : success == Summary == Series 38376v1 drm/i915: Assert that we always complete a submission to guc/execlists

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Prune gen8_gt_irq_handler

Quoting Chris Wilson (2018-02-15 07:37:13) > if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) { > - gt_iir[0] = I915_READ_FW(GEN8_GT_IIR(0)); > - if (gt_iir[0]) > - I915_WRITE_FW(GEN8_GT_IIR(0), gt_iir[0]); > + gt_iir[0]

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Release connector iterator on a digital port conflict.

== Series Details == Series: drm/i915: Release connector iterator on a digital port conflict. URL : https://patchwork.freedesktop.org/series/38330/ State : success == Summary == Test kms_flip: Subgroup plain-flip-ts-check-interruptible: pass -> FAIL

Re: [Intel-gfx] [PATCH 05/19] drm/i915/icl: Interrupt handling

On 15/02/2018 16:27, Mika Kuoppala wrote: From: Tvrtko Ursulin I think a point has arrived when I almost don't recognize the code any longer so would want to relinquish the authorship if you don't mind. Regards, Tvrtko v2: Rebase. v3: * Remove DPF, it has

Re: [Intel-gfx] [PATCH] drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERR

Quoting Gustavo A. R. Silva (2018-02-15 16:09:09) > > > On 02/15/2018 03:13 AM, Jani Nikula wrote: > > On Wed, 14 Feb 2018, "Gustavo A. R. Silva" wrote: > >> Fix inconsistent IS_ERR and PTR_ERR in shrink_boom. > >> The proper pointer to use is _explode_ instead of

Re: [Intel-gfx] [PATCH] drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERR

On 02/15/2018 03:13 AM, Jani Nikula wrote: On Wed, 14 Feb 2018, "Gustavo A. R. Silva" wrote: Fix inconsistent IS_ERR and PTR_ERR in shrink_boom. The proper pointer to use is _explode_ instead of _purge_. This issue was detected with the help of Coccinelle. Fixes:

[Intel-gfx] [PATCH 05/19] drm/i915/icl: Interrupt handling

From: Tvrtko Ursulin v2: Rebase. v3: * Remove DPF, it has been removed from SKL+. * Fix -internal rebase wrt. execlists interrupt handling. v4: Rebase. v5: * Updated for POR changes. (Daniele Ceraolo Spurio) * Merged with irq handling fixes by Daniele Ceraolo

Re: [Intel-gfx] [PATCH 05/19] drm/i915/icl: Interrupt handling

Chris Wilson writes: > Quoting Mika Kuoppala (2018-02-14 14:12:13) >> From: Tvrtko Ursulin >> >> v2: Rebase. >> >> v3: >> * Remove DPF, it has been removed from SKL+. >> * Fix -internal rebase wrt. execlists interrupt handling. >> >>

[Intel-gfx] [PATCH] drm/i915: Assert that we always complete a submission to guc/execlists

The continual resubmission model for execlists (and emulated over guc) requires that we keep feeding requests into the HW in order to generate more CS interrupts to drain the rest of the queue. Add a couple of asserts to ensure that we don't skip a cycle and come to a grinding halt.

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Avoid escaping check_digital_port_conflicts() with locks held

== Series Details == Series: drm/i915: Avoid escaping check_digital_port_conflicts() with locks held URL : https://patchwork.freedesktop.org/series/38331/ State : success == Summary == Test perf_pmu: Subgroup semaphore-wait-vcs0: pass -> FAIL (shard-apl)

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Track GT interrupt handling using the master iir

Quoting Mika Kuoppala (2018-02-15 15:21:33) > Chris Wilson writes: > > > Keep the master iir and use it to reduce the number of reads and writes > > to the GT iir array, i.e. only the bits marked as set by the master iir > > are valid inside GT iir array and will be

[Intel-gfx] [PATCH i-g-t v6] tests/perf_pmu: Verify engine busyness accuracy

From: Tvrtko Ursulin A subtest to verify that the engine busyness is reported with expected accuracy on platforms where the feature is available. We test three patterns: 2%, 50% and 98% load per engine. v2: * Use spin batch instead of nop calibration. * Various

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Release connector iterator on a digital port conflict.

== Series Details == Series: drm/i915: Release connector iterator on a digital port conflict. URL : https://patchwork.freedesktop.org/series/38330/ State : warning == Summary == Test perf: Subgroup enable-disable: fail -> PASS (shard-apl) fdo#103715 Test

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Track GT interrupt handling using the master iir

Chris Wilson writes: > Keep the master iir and use it to reduce the number of reads and writes > to the GT iir array, i.e. only the bits marked as set by the master iir > are valid inside GT iir array and will be handled during the interrupt. > > Signed-off-by: Chris

Re: [Intel-gfx] [RFC 4/5] drm/i915: Expose per-engine client busyness

On 15/02/2018 09:44, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-02-15 09:41:53) On 14/02/2018 19:17, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-02-14 18:50:34) From: Tvrtko Ursulin Expose per-client and per-engine busyness under the previously added

Re: [Intel-gfx] [PATCH] drm/i915/audio: fix check for av_enc_map overflow

On Thu, 15 Feb 2018, Mika Kahola wrote: > On Wed, 2018-02-14 at 19:38 +0200, Jani Nikula wrote: >> Turns out -1 >= ARRAY_SIZE() is always true. Move the bounds check >> where >> we know pipe >= 0 and next to the array indexing where it makes most >> sense. >> >> Fixes:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915: Store gen_mask inside the static device info

== Series Details == Series: series starting with [v2,1/3] drm/i915: Store gen_mask inside the static device info URL : https://patchwork.freedesktop.org/series/38317/ State : success == Summary == Test perf: Subgroup oa-exponents: pass -> FAIL (shard-apl)

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use seqlock in engine stats (rev2)

== Series Details == Series: drm/i915: Use seqlock in engine stats (rev2) URL : https://patchwork.freedesktop.org/series/38347/ State : success == Summary == Series 38347v2 drm/i915: Use seqlock in engine stats https://patchwork.freedesktop.org/api/1.0/series/38347/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Enable VBT based BL control for DP (v2)

On Wed, 14 Feb 2018, "Mustaffa, Mustamin B" wrote: > Hi Jani, > > I able to figure out using intel_dp structure instead of dev_priv. > > Should I continue using dev_priv or intel_dp? > > - int backlight_controller = dev_priv->vbt.backlight.controller; > +

Re: [Intel-gfx] [PATCH] drm/i915/gtt: Convert WARN_ON to GEM debugging

On 15 February 2018 at 11:07, Chris Wilson wrote: > As we presume that we have sufficient coverage of CI for new machines > and new code paths, we do not need to have user impacting WARN_ON for > programming errors inside i915_gem_gtt.c, so convert those over to >

Re: [Intel-gfx] [PATCH 1/3] drm/i915/cnl: Fix PORT_TX_DW5/7 register address

On Thu, 15 Feb 2018, Mahesh Kumar wrote: > Register Address for CNL_PORT_DW5_LN0_D is 0x162E54, but current code is > defining it as 0x162ED4. Similarly for CNL_PORT_DW7_LN0_D register address > is defined 0x162EDC instead of 0x162E5C, fix it. Which commit introduced the

Re: [Intel-gfx] [PATCH v3] drm/i915: Clean up ancient doc comments for i915_ioc32.c

On Thu, 15 Feb 2018, Chris Wilson wrote: > Quoting Chris Wilson (2018-02-14 16:07:20) >> As befitting a file dedicated to the mistakes of the past, >> >> drivers/gpu/drm/i915/i915_ioc32.c:2: warning: Cannot understand * \file >> i915_ioc32.c >> on line 2 - I thought

Re: [Intel-gfx] [PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature

On Wed, 14 Feb 2018, Anusha Srivatsa wrote: > Forward Error Correction is supported on DP 1.4. > This patch adds corresponding DPCD register definitions. > > v2: Add dri-devel mailing list to the CC list(Jani) > > v3: Change names, add missing masks (Manasi) > > v4: Add

[Intel-gfx] [PATCH] drm/i915/selftests: fix inconsistent IS_ERR and PTR_ERR

Fix inconsistent IS_ERR and PTR_ERR in shrink_boom. The proper pointer to use is _explode_ instead of _purge_. This issue was detected with the help of Coccinelle. Fixes: fe215c8bc426 ("drm/i915/selftests: add missing gtt shrinker test") Signed-off-by: Gustavo A. R. Silva

[Intel-gfx] [PATCH v2] drm/i915: Use seqlock in engine stats

From: Tvrtko Ursulin We can convert engine stats from a spinlock to seqlock to ensure interrupt processing is never even a tiny bit delayed by parallel readers. There is a smidgen bit more cost on the write lock side, and an extremely unlikely chance that readers will

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Track GT interrupt handling using the master iir

== Series Details == Series: series starting with [1/2] drm/i915: Track GT interrupt handling using the master iir URL : https://patchwork.freedesktop.org/series/38314/ State : success == Summary == Test kms_setmode: Subgroup basic: fail -> PASS

Re: [Intel-gfx] [PATCH i-g-t] tests/perf_pmu: Log perf timestamp in semaphore wait tests

Quoting Tvrtko Ursulin (2018-02-15 11:25:15) > From: Tvrtko Ursulin > > We need more data to debug sporadic test failures. > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson -Chris

[Intel-gfx] ✗ Fi.CI.IGT: warning for Adding NV12 support (rev11)

== Series Details == Series: Adding NV12 support (rev11) URL : https://patchwork.freedesktop.org/series/28103/ State : warning == Summary == Test kms_flip: Subgroup dpms-vs-vblank-race: pass -> DMESG-WARN (shard-hsw) fdo#103060 Subgroup

Re: [Intel-gfx] [PATCH i-g-t] tests/perf_pmu: Verify engine busyness accuracy

Quoting Tvrtko Ursulin (2018-02-15 11:53:44) > From: Tvrtko Ursulin > > A subtest to verify that the engine busyness is reported with expected > accuracy on platforms where the feature is available. > > We test three patterns: 2%, 50% and 98% load per engine. > > v2:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: expose RCS topology to userspace

== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/38356/ State : success == Summary == Series 38356v1 drm/i915: expose RCS topology to userspace https://patchwork.freedesktop.org/api/1.0/series/38356/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/mm: Fix caching of leftmost node in the interval tree

Quoting Chris Wilson (2018-02-15 11:36:51) > When we descend the tree to find our slot, if we step to the right, we > are no longer the leftmost node. Fortunately, the cached leftmost node is unused here and no drm_mm API exposes it. So probably doesn't make sense to send it to stable@ as no bug

Re: [Intel-gfx] [PATCH 06/10] drm/tegra: Handle 64-bit return from drm_crtc_vblank_count()

On Wed, Feb 07, 2018 at 01:41:18AM +, Pandiyan, Dhinakaran wrote: > On Fri, 2018-02-02 at 21:12 -0800, Dhinakaran Pandiyan wrote: > > 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the > > return type for drm_crtc_vblank_count() to u64. This could cause > > potential problems

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Remove alpha_support protection

Quoting Rodrigo Vivi (2018-02-14 22:42:05) > We now have a stable cnl on our CI and it seems mostly > green without big risks of blank screen or anything > blowing up on linux installations in the future. > > As a reminder i915.alpha_support was created to protect > future linux installation's

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: expose RCS topology to userspace

== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/38356/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: store all subslice masks Okay! Commit: drm/i915/debugfs: reuse max slice/subslices already

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: expose RCS topology to userspace

== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/38356/ State : warning == Summary == $ dim checkpatch origin/drm-tip b98af10ebabc drm/i915: store all subslice masks -:344: CHECK: spaces preferred around that '*' (ctx:VxV)

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/mm: Fix caching of leftmost node in the interval tree

== Series Details == Series: drm/mm: Fix caching of leftmost node in the interval tree URL : https://patchwork.freedesktop.org/series/38351/ State : success == Summary == Series 38351v1 drm/mm: Fix caching of leftmost node in the interval tree

Re: [Intel-gfx] [PATCH] drm/i915: Use seqlock in engine stats

Quoting Tvrtko Ursulin (2018-02-15 11:59:06) > > On 15/02/2018 11:47, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-02-15 11:13:33) > >> From: Tvrtko Ursulin > >> > >> We can convert engine stats from a spinlock to seqlock to ensure interrupt > >> processing is

[Intel-gfx] [PATCH v13 4/6] drm/i915: add rcs topology to error state

This might be useful information for developers looking at an error state. v2: Place topology towards the end of the error state (Chris) v3: Reuse common printing code (Michal) v4: Make this a one-liner (Chris) Signed-off-by: Lionel Landwerlin Reviewed-by:

[Intel-gfx] [PATCH v13 6/6] drm/i915: expose rcs topology through query uAPI

With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts

[Intel-gfx] [PATCH v13 5/6] drm/i915: add query uAPI

There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are execution units grouped in subslices and slices and also which ones have been fused off for die

[Intel-gfx] [PATCH v13 3/6] drm/i915/debugfs: add rcs topology entry

While the end goal is to make this information available to userspace through a new ioctl, there is no reason we can't display it in a human readable fashion through debugfs. slice0: 3 subslice(s) (0x7): subslice0: 8 EUs (0xff) subslice1: 8 EUs (0xff) subslice2: 8 EUs

[Intel-gfx] [PATCH v13 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

Now that we have that information in topology fields, let's just reuse it. v2: Style tweaks (Tvrtko) Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 27 +++

[Intel-gfx] [PATCH v13 0/6] drm/i915: expose RCS topology to userspace

Hi all, After some discussion with Joonas we agreed on changing some of the rcs topology structs in the uAPI. It now uses a single struct instead of 3. I've also changed the bit the query uAPI to make it more sensible to userspace (please see comment in patch 5). Therefore dropping the Rb on

[Intel-gfx] [PATCH v13 1/6] drm/i915: store all subslice masks

Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymmetric (for example slice0 has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all

Re: [Intel-gfx] [PATCH] drm/i915: Use seqlock in engine stats

On 15/02/2018 11:47, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-02-15 11:13:33) From: Tvrtko Ursulin We can convert engine stats from a spinlock to seqlock to ensure interrupt processing is never even a tiny bit delayed by parallel readers. There is a smidgen

[Intel-gfx] [PATCH i-g-t] tests/perf_pmu: Verify engine busyness accuracy

From: Tvrtko Ursulin A subtest to verify that the engine busyness is reported with expected accuracy on platforms where the feature is available. We test three patterns: 2%, 50% and 98% load per engine. v2: * Use spin batch instead of nop calibration. * Various

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use seqlock in engine stats

== Series Details == Series: drm/i915: Use seqlock in engine stats URL : https://patchwork.freedesktop.org/series/38347/ State : success == Summary == Series 38347v1 drm/i915: Use seqlock in engine stats https://patchwork.freedesktop.org/api/1.0/series/38347/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915: Use seqlock in engine stats

Quoting Tvrtko Ursulin (2018-02-15 11:13:33) > From: Tvrtko Ursulin > > We can convert engine stats from a spinlock to seqlock to ensure interrupt > processing is never even a tiny bit delayed by parallel readers. > > There is a smidgen bit more cost on the write lock

[Intel-gfx] [PATCH] drm/mm: Fix caching of leftmost node in the interval tree

When we descend the tree to find our slot, if we step to the right, we are no longer the leftmost node. Fixes: f808c13fd373 ("lib/interval_tree: fast overlap detection") Signed-off-by: Chris Wilson Cc: Davidlohr Bueso Cc: Jérôme Glisse

[Intel-gfx] ✗ Fi.CI.IGT: failure for Adding NV12 support (rev11)

== Series Details == Series: Adding NV12 support (rev11) URL : https://patchwork.freedesktop.org/series/28103/ State : failure == Summary == Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 Test perf: Subgroup enable-disable:

Re: [Intel-gfx] [PATCH 03/16] drm/i915/skl+: add NV12 in skl_format_to_fourcc

From: Sharma, Shashank Sent: Thursday, February 8, 2018 12:17 PM To: Srinivas, Vidya ; intel-gfx@lists.freedesktop.org Cc: maarten.lankho...@linux.intel.com; Kamath, Sunil ; Shankar, Uma ; Kumar, Mahesh1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gtt: Convert WARN_ON to GEM debugging

== Series Details == Series: drm/i915/gtt: Convert WARN_ON to GEM debugging URL : https://patchwork.freedesktop.org/series/38346/ State : success == Summary == Series 38346v1 drm/i915/gtt: Convert WARN_ON to GEM debugging

[Intel-gfx] [PATCH i-g-t] tests/perf_pmu: Log perf timestamp in semaphore wait tests

From: Tvrtko Ursulin We need more data to debug sporadic test failures. Signed-off-by: Tvrtko Ursulin --- tests/perf_pmu.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c

[Intel-gfx] [PATCH] drm/i915: Use seqlock in engine stats

From: Tvrtko Ursulin We can convert engine stats from a spinlock to seqlock to ensure interrupt processing is never even a tiny bit delayed by parallel readers. There is a smidgen bit more cost on the write lock side, and an extremely unlikely chance that readers will

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/gem_exec_schedule: Trim max number of contexts used

== Series Details == Series: igt/gem_exec_schedule: Trim max number of contexts used URL : https://patchwork.freedesktop.org/series/38344/ State : failure == Summary == IGT patchset tested on top of latest successful build 0a700e095b2a47e99081b7bffce1e737863e0136 igt/gem_exec_fence: Test that

[Intel-gfx] [PATCH] drm/i915/gtt: Convert WARN_ON to GEM debugging

As we presume that we have sufficient coverage of CI for new machines and new code paths, we do not need to have user impacting WARN_ON for programming errors inside i915_gem_gtt.c, so convert those over to GEM_BUG_ON. This leaves the memory debugging WARN_ON in place as they are not so easy to

Re: [Intel-gfx] [PATCH 16/16] drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg

My previous review comment for alignment is not addressed in this patch. Regards Shashank On 2/14/2018 10:27 AM, Vidya Srinivas wrote: If the fb format is YUV, enable the plane CSC mode bits for the conversion. Signed-off-by: Vidya Srinivas ---

Re: [Intel-gfx] [PATCH 16/16] drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg

My previous review comment for alignment has not been addressed in this series Regards Shashank On 2/14/2018 10:27 AM, Vidya Srinivas wrote: If the fb format is YUV, enable the plane CSC mode bits for the conversion. Signed-off-by: Vidya Srinivas ---

Re: [Intel-gfx] [RFC 0/5] Per-client engine stats

On 15/02/2018 09:47, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-02-15 09:44:58) On 14/02/2018 19:20, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-02-14 18:50:30) From: Tvrtko Ursulin Another re-post of my earlier, now slightly updated work, to expose a

[Intel-gfx] [PATCH igt v3] igt/gem_exec_schedule: Trim max number of contexts used

icl offers a much reduced context space, and in its simplest setup we cannot allocate one context per priority level, so trim the number and reuse the same context for multiple priority requests. v2: Bump the MAX to 1024 (still lower than the ~4096 previously in use) v3: Also limit NCTX to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Release connector iterator on a digital port conflict.

== Series Details == Series: drm/i915: Release connector iterator on a digital port conflict. URL : https://patchwork.freedesktop.org/series/38330/ State : success == Summary == Series 38330v1 drm/i915: Release connector iterator on a digital port conflict.

[Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Use smallest mode by default

A situation we have in the CI farm is that the only machine capable of performing PSR also happens to have a large panel, too large for PSR to handle. Flip the small-mode option to enable using the smallest mode by default, and selecting the preferred mode as the option. Signed-off-by: Chris

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Release connector iterator on a digital port conflict.

== Series Details == Series: drm/i915: Release connector iterator on a digital port conflict. URL : https://patchwork.freedesktop.org/series/38330/ State : warning == Summary == $ dim checkpatch origin/drm-tip 140a43336772 drm/i915: Release connector iterator on a digital port conflict. -:13:

  1   2   >