Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Fix premature LRC unpin in GuC mode

On Thu, Jan 21, 2016 at 10:10:42AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > In GuC mode LRC pinning lifetime depends exclusively on the > request liftime. Since that is terminated by the seqno update > that opens up a race condition between GPU finishing

Re: [Intel-gfx] [PATCH 2/8] drm/i915/gen9: Add GEN8_CS_CHICKEN1 to HW whitelist

On 13/01/2016 10:06, Arun Siluvery wrote: Required for WaEnablePreemptionGranularityControlByUMD:skl,bxt Signed-off-by: Arun Siluvery Reviewed-by: Nick Hoath --- drivers/gpu/drm/i915/i915_reg.h | 2 ++

Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: Fix premature LRC unpin in GuC mode

On Thu, Jan 21, 2016 at 12:14:10PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > In GuC mode LRC pinning lifetime depends exclusively on the > request liftime. Since that is terminated by the seqno update > that opens up a race condition between GPU finishing

Re: [Intel-gfx] [PATCH 04/25] drm/i915/fbc: introduce struct intel_fbc_reg_params

Op 19-01-16 om 14:35 schreef Paulo Zanoni: > The early return inside __intel_fbc_update does not completely check > all the parameters that affect the FBC register values. For example, > we currently lack looking at crtc->adjusted_y (for the fence Y offset) > and all the parameters that affect the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/skl/kbl: Add support for pipe fusing (rev3)

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest bdw-nuci7total:140 pass:131 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:143 pass:137 dwarn:0 dfail:0 fail:0 skip:6

Re: [Intel-gfx] [PATCH 15/25] drm/i915/fbc: rewrite the multiple_pipes_ok() code for locking

Op 19-01-16 om 14:35 schreef Paulo Zanoni: > Older FBC platforms have this restriction where FBC can't be enabled > if multiple pipes are enabled. In the current code, we disable FBC > before the second pipe becomes visible. > > One of the problems with this code is that the current >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/4] drm/i915: Make LRC (un)pinning work on context and engine

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) bdw-nuci7total:140 pass:131 dwarn:0

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Instrument PSR parameter for possible quirks with link standby.

Em Qui, 2016-01-21 às 08:35 +0530, Thulasimani, Sivakumar escreveu: > > On 1/20/2016 10:32 PM, Zanoni, Paulo R wrote: > > Em Sex, 2015-12-11 às 08:39 -0800, Rodrigo Vivi escreveu: > > > Unfortunately we don't know all panels and platforms out there > > > and we > > > found internal prototypes

Re: [Intel-gfx] [PATCH 4/8] drm/i915/bxt: Add GEN9_CS_DEBUG_MODE1 to HW whitelist

On 13/01/2016 10:06, Arun Siluvery wrote: Required for, WaDisableObjectLevelPreemptionForTrifanOrPolygon:bxt WaDisableObjectLevelPreemptionForInstancedDraw:bxt WaDisableObjectLevelPreemtionForInstanceId:bxt According to WA database these are only applicable for BXT:A0 but since A0 and A1 shares

Re: [Intel-gfx] [PATCH 14/18] drm/i915: Embed rotation_info under intel_framebuffer

On Thu, Jan 21, 2016 at 02:06:27PM +0200, Ville Syrjälä wrote: > On Wed, Jan 20, 2016 at 09:08:50PM +, Chris Wilson wrote: > > On Wed, Jan 20, 2016 at 09:05:35PM +0200, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > Instead of

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Instrument PSR parameter for possible quirks with link standby.

On 1/21/2016 5:26 PM, Zanoni, Paulo R wrote: Em Qui, 2016-01-21 às 08:35 +0530, Thulasimani, Sivakumar escreveu: On 1/20/2016 10:32 PM, Zanoni, Paulo R wrote: Em Sex, 2015-12-11 às 08:39 -0800, Rodrigo Vivi escreveu: Unfortunately we don't know all panels and platforms out there and we

Re: [Intel-gfx] [PATCH 08/25] drm/i915/fbc: unconditionally update FBC during atomic commits

Op 19-01-16 om 14:35 schreef Paulo Zanoni: > We unconditionally disable/update FBC even during the page flip > IOCTLs, and an unconditional disable/update at every atomic commit > touching the primary plane shouldn't impact PC state residency > noticeably. Besides, the code that checks for

Re: [Intel-gfx] [RFC 14/22] drm/i915/slpc: Notification of Display mode change

Em Qua, 2016-01-20 às 18:26 -0800, tom.orou...@intel.com escreveu: > From: Sagar Arun Kamble > > GuC SLPC need to be sent data related to Active pipes, refresh rates, > widi pipes, fullscreen pipes related via host to GuC display mode > change event. > This patch

Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: Fix premature LRC unpin in GuC mode

On 21/01/16 12:32, Chris Wilson wrote: On Thu, Jan 21, 2016 at 12:14:10PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin In GuC mode LRC pinning lifetime depends exclusively on the request liftime. Since that is terminated by the seqno update that opens up a race

Re: [Intel-gfx] [PATCH 02/25] drm/i915/fbc: extract intel_fbc_can_activate()

Op 19-01-16 om 14:35 schreef Paulo Zanoni: > Extract all the code that checks if the FBC configuration is valid to > its own function, making __intel_fbc_update() much simpler. > > Signed-off-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_fbc.c | 92 >

Re: [Intel-gfx] [PATCH 3/8] drm/i915/gen9: Add HDC_CHICKEN1 to HW whitelist

On 13/01/2016 10:06, Arun Siluvery wrote: Required for WaAllowUMDToModifyHDCChicken1:skl,bxt Signed-off-by: Arun Siluvery Reviewed-by: Nick Hoath --- drivers/gpu/drm/i915/i915_reg.h | 2 ++

Re: [Intel-gfx] [PATCH 04/25] drm/i915/fbc: introduce struct intel_fbc_reg_params

Em Qui, 2016-01-21 às 13:48 +0100, Maarten Lankhorst escreveu: > Op 19-01-16 om 14:35 schreef Paulo Zanoni: > > The early return inside __intel_fbc_update does not completely > > check > > all the parameters that affect the FBC register values. For > > example, > > we currently lack looking at

Re: [Intel-gfx] [PATCH 08/25] drm/i915/fbc: unconditionally update FBC during atomic commits

Em Qui, 2016-01-21 às 14:04 +0100, Maarten Lankhorst escreveu: > Op 19-01-16 om 14:35 schreef Paulo Zanoni: > > We unconditionally disable/update FBC even during the page flip > > IOCTLs, and an unconditional disable/update at every atomic commit > > touching the primary plane shouldn't impact PC

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

On 15/01/16 11:24, Patchwork wrote: == Summary == Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly: 2016y-01m-15d-09h-46m-32s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7)

Re: [Intel-gfx] [PATCH] drm/i915: Acquire RPM wakeref for KMS atomic commit

On to, 2016-01-14 at 18:50 +0200, Imre Deak wrote: > On la, 2015-12-19 at 09:58 +, Chris Wilson wrote: > > Once all the preparations are complete, we are ready to write the > > modesetting to the hardware. During this phase, we will be making > > lots > > of HW register access, so take a top

Re: [Intel-gfx] [PATCH 02/25] drm/i915/fbc: extract intel_fbc_can_activate()

Em Qui, 2016-01-21 às 12:35 +0100, Maarten Lankhorst escreveu: > Op 19-01-16 om 14:35 schreef Paulo Zanoni: > > Extract all the code that checks if the FBC configuration is valid > > to > > its own function, making __intel_fbc_update() much simpler. > > > > Signed-off-by: Paulo Zanoni

Re: [Intel-gfx] [PATCH 14/18] drm/i915: Embed rotation_info under intel_framebuffer

On Wed, Jan 20, 2016 at 09:08:50PM +, Chris Wilson wrote: > On Wed, Jan 20, 2016 at 09:05:35PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Instead of repopulatin the rotation_info struct for the fb every time > > we try to use

[Intel-gfx] [PATCH 3/4] drm/i915: Extract context unpinning to its own function

From: Tvrtko Ursulin Will enable cleaner implementation of a following fix and easier code unification in the future. Idea and code by Chris Wilson. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson ---

[Intel-gfx] [PATCH v2 1/4] drm/i915: Make LRC (un)pinning work on context and engine

From: Tvrtko Ursulin Previously intel_lr_context_(un)pin were operating on requests which is in conflict with their names. If we make them take a context and an engine, it makes the names make more sense and it also makes future fixes possible. v2: Rebase for

[Intel-gfx] [PATCH v2 2/4] drm/i915: Make LRC pinning own a reference to the context

From: Tvrtko Ursulin Will simplify the following fix and sounds logical. v2: Add some whitespace to separate logic better. (Chris Wilson) Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson Cc: Chris Wilson

Re: [Intel-gfx] [PATCH 5/8] drm/i915/bxt: Add GEN8_L3SQCREG4 to HW whitelist

On 13/01/2016 10:06, Arun Siluvery wrote: Required for WaDisableLSQCROPERFforOCL:bxt According to WA database these are only applicable for BXT:A0 but since A0 and A1 shares the same GT these are extended for A1 as well. Signed-off-by: Arun Siluvery

Re: [Intel-gfx] [PATCH 6/8] drm/i915/skl: Add GEN8_L3SQCREG4 to HW whitelist

On 13/01/2016 10:06, Arun Siluvery wrote: Required for WaDisableLSQCROPERFforOCL:skl Signed-off-by: Arun Siluvery Reviewed-by: Nick Hoath --- drivers/gpu/drm/i915/intel_ringbuffer.c | 5 + 1 file changed, 5 insertions(+)

[Intel-gfx] [PATCH v4 4/4] drm/i915: Fix premature LRC unpin in GuC mode

From: Tvrtko Ursulin In GuC mode LRC pinning lifetime depends exclusively on the request liftime. Since that is terminated by the seqno update that opens up a race condition between GPU finishing writing out the context image and the driver unpinning the LRC. To extend

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic (v2)

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest bdw-nuci7total:140 pass:131 dwarn:0 dfail:0 fail:0 skip:9 bdw-ultratotal:143 pass:137 dwarn:0 dfail:0 fail:0 skip:6

[Intel-gfx] [PATCH v2 5/8] drm/i915/bxt: Add GEN8_L3SQCREG4 to HW whitelist

Required for WaDisableLSQCROPERFforOCL:bxt According to WA database these are only applicable for BXT:A0 but since A0 and A1 shares the same GT these are extended for A1 as well. Reviewed-by: Nick Hoath Signed-off-by: Arun Siluvery ---

[Intel-gfx] [PATCH v2 3/8] drm/i915/gen9: Add HDC_CHICKEN1 to HW whitelist

Required for WaAllowUMDToModifyHDCChicken1:skl,bxt Reviewed-by: Nick Hoath Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_ringbuffer.c | 5 + 2 files changed, 7

[Intel-gfx] [PATCH v2 1/8] drm/i915/gen9: Add framework to whitelist specific GPU registers

Some of the HW registers are privileged and cannot be written to from non-privileged batch buffers coming from userspace unless they are added to the HW whitelist. This whitelist is maintained by HW and it is different from SW whitelist. Userspace need write access to them to implement preemption

[Intel-gfx] [PATCH v2 8/8] drm/i915/gen9: Add WaOCLCoherentLineFlush

This is mainly required for preemption. Cc: Dave Gordon Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_ringbuffer.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c

[Intel-gfx] [PATCH v2 2/8] drm/i915/gen9: Add GEN8_CS_CHICKEN1 to HW whitelist

Required for WaEnablePreemptionGranularityControlByUMD:skl,bxt Reviewed-by: Nick Hoath Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_ringbuffer.c | 6 ++ 2 files changed,

[Intel-gfx] [PATCH v2 7/8] drm/i915/skl: Enable Per context Preemption granularity control

Per context preemption granularity control is only available from SKL:E0+ Cc: Dave Gordon Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++ 2 files

[Intel-gfx] [PATCH v2 6/8] drm/i915/skl: Add GEN8_L3SQCREG4 to HW whitelist

Required for WaDisableLSQCROPERFforOCL:skl Reviewed-by: Nick Hoath Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_ringbuffer.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c

[Intel-gfx] [PATCH v2 4/8] drm/i915/bxt: Add GEN9_CS_DEBUG_MODE1 to HW whitelist

Required for, WaDisableObjectLevelPreemptionForTrifanOrPolygon:bxt WaDisableObjectLevelPreemptionForInstancedDraw:bxt WaDisableObjectLevelPreemtionForInstanceId:bxt According to WA database these are only applicable for BXT:A0 but since A0 and A1 shares the same GT these are extended for A1 as

Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: Fix premature LRC unpin in GuC mode

On Thu, Jan 21, 2016 at 01:51:30PM +, Tvrtko Ursulin wrote: > But I can't really figure where would you put this poisoning? You > could put something in in exec list mode after context complete and > check it before it is used next time, I was thinking just in context-free. Move the pages to

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Decouple execbuf uAPI from internal implementation (rev2)

On 15/01/16 17:20, Patchwork wrote: == Summary == Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly: 2016y-01m-15d-09h-46m-32s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Fix premature LRC unpin in GuC mode

On Thu, Jan 21, 2016 at 11:02:50AM +, Chris Wilson wrote: > intel_gpu_reset(); > for_each_engine() unpin(engine->last_context); > unpin(dev_priv->default_context); > > After a few more passes, we should be able to call the reset and cleanup > functions higher up (as part of the stopping the

[Intel-gfx] [PATCH v2 0/8] Gen9 HW whitelist and Preemption WA patches

Resending all patches as told by Daniel because I didn't use correct message-id while replying updated version of Patch1 before which means patchwork won't pickup and we won't have CI results. Previous updates regarding Patch1 are available at https://patchwork.freedesktop.org/patch/70527/ Some

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Tune down "GT register while GT waking disabled" message

== Summary == Built on c783b5011894af49992f2095cb2848b6cf8ebc57 drm-intel-nightly: 2016y-01m-20d-10h-12m-03s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (bdw-ultra) UNSTABLE Test gem_sync: Subgroup basic-render:

Re: [Intel-gfx] [PATCH v4] drm/i915: edp resume/On time optimization.

On 1/20/2016 5:06 AM, Ville Syrjälä wrote: On Wed, Jan 20, 2016 at 03:29:00PM +0530, Kumar, Shobhit wrote: On 01/20/2016 02:30 PM, Daniel Vetter wrote: On Tue, Jan 19, 2016 at 02:37:55PM -0800, Kumar, Abhay wrote: On 1/12/2016 5:57 PM, Kumar, Abhay wrote: From: Abhay Kumar

Re: [Intel-gfx] [PATCH 08/25] drm/i915/fbc: unconditionally update FBC during atomic commits

Op 21-01-16 om 14:27 schreef Zanoni, Paulo R: > Em Qui, 2016-01-21 às 14:04 +0100, Maarten Lankhorst escreveu: >> Op 19-01-16 om 14:35 schreef Paulo Zanoni: >>> We unconditionally disable/update FBC even during the page flip >>> IOCTLs, and an unconditional disable/update at every atomic commit

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add support for GuC-based SLPC

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test drv_getparams_basic: Subgroup basic-eu-total: pass -> DMESG-FAIL (skl-i5k-2) Subgroup basic-subslice-total:

Re: [Intel-gfx] [PATCH] drm/i915: Tune down "GT register while GT waking disabled" message

Mika Kuoppala writes: > Daniel Vetter writes: > >> We've had this since forever, and's randomly reporting issues and as >> such causing piles of CI noise. Mika is working on proper debug >> infrastructure for this, and on fixing this

Re: [Intel-gfx] [PATCH v2] drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

On Fri, Jan 15, 2016 at 04:51:46PM +, Chris Wilson wrote: > Tvrtko was looking through the execbuffer-ioctl and noticed that the > uABI was tightly coupled to our internal engine identifiers. Close > inspection also revealed that we leak those internal engine identifiers > through the

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for improve handling of the driver's default (kernel) context

On Wed, Jan 20, 2016 at 05:31:00PM +, Dave Gordon wrote: > On 20/01/16 07:49, Patchwork wrote: > >== Summary == > > > >Built on 7d26528d30b0d8119c858115b6e5e22deb74ec71 drm-intel-nightly: > >2016y-01m-19d-19h-38m-52s UTC integration manifest > > > >Test gem_storedw_loop: > > Subgroup

[Intel-gfx] [PATCH i-g-t 1/2 v2] lib/ioctl_wrappers: Add gem_gtt_type exposing raw HAS_ALIASING_PPGTT param

No functional changes. While I'm here, let's also rename gem_uses_aliasing_ppgtt (since it's being used to indicate if we are using ANY kind of ppgtt) and introduce gem_uses_full_ppgtt to drop some unnecessary code from tests that were previously calling getparam directly instead of using ioctl

Re: [Intel-gfx] [PATCH] drm/i915: Limit the auto arming of mmio debugs on vlv/chv

Daniel Vetter writes: > On Wed, Jan 20, 2016 at 12:32:23PM +0200, Mika Kuoppala wrote: >> The capability to detect unclaimed register access was >> recently introduced for vlv/chv platforms. Apparently >> there are plenty of unclaimed access on these platforms, >> resulting in

[Intel-gfx] [PATCH 2/3] drm/i915: Make LRC pinning own a reference to the context

From: Tvrtko Ursulin Will simplify the following fix and sounds logical. v2: Add some whitespace to separate logic better. (Chris Wilson) Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson Cc: Chris Wilson

Re: [Intel-gfx] [PATCH v2] drm/i915: Decouple execbuf uAPI from internal implementation

On Fri, Jan 15, 2016 at 03:12:50PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > At the moment execbuf ring selection is fully coupled to > internal ring ids which is not a good thing on its own. > > This dependency is also spread between two source files and

Re: [Intel-gfx] [PATCH igt] igt/gem_softpin: Remove false dependencies on esoteric features

On Wed, Jan 20, 2016 at 06:49:49PM +, Belgaumkar, Vinay wrote: > Hi Chris, > These tests were developed for testing buffered SVM(using userptr > and soft pinning API). I think Dan wanted me to rename the tests to > gem_softpin, since they were being checked in as tests which >

[Intel-gfx] [PATCH v3 3/3] drm/i915: Fix premature LRC unpin in GuC mode

From: Tvrtko Ursulin In GuC mode LRC pinning lifetime depends exclusively on the request liftime. Since that is terminated by the seqno update that opens up a race condition between GPU finishing writing out the context image and the driver unpinning the LRC. To extend

[Intel-gfx] [PATCH v2 1/3] drm/i915: Make LRC (un)pinning work on context and engine

From: Tvrtko Ursulin Previously intel_lr_context_(un)pin were operating on requests which is in conflict with their names. If we make them take a context and an engine, it makes the names make more sense and it also makes future fixes possible. v2: Rebase for

Re: [Intel-gfx] [PATCH v4 0/3] improve handling of the driver's default (kernel) context

On Tue, Jan 19, 2016 at 07:02:52PM +, Dave Gordon wrote: > During startup, the driver creates a unique "intel_context" that will > provide a home for orphan requests (i.e. those generated by the driver > internally, not associated with user batchbuffers). > > However, one of the infelicities

Re: [Intel-gfx] [PATCH] drm/i915: Do not put big intel_crtc_state on the stack

On Tue, 19 Jan 2016, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Having this on stack triggers the -Wframe-larger-than=1024 and > is not nice to put such big things on the kernel stack anyway. > > This required a little bit of

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Use ordered seqno write interrupt generation on gen8+ execlists

Patchwork writes: > == Summary == > > Built on e9545b0b60b73d8be3d41048af5b8f2c1e2fc4c1 drm-intel-nightly: > 2016y-01m-20d-13h-55m-37s UTC integration manifest > > Test gem_storedw_loop: > Subgroup basic-render: > dmesg-warn -> PASS

Re: [Intel-gfx] [PATCH i-g-t 1/2 v2] lib/ioctl_wrappers: Add gem_gtt_type exposing raw HAS_ALIASING_PPGTT param

On Thu, Jan 21, 2016 at 10:27:26AM +0100, Michał Winiarski wrote: > No functional changes. > While I'm here, let's also rename gem_uses_aliasing_ppgtt (since it's > being used to indicate if we are using ANY kind of ppgtt) and introduce > gem_uses_full_ppgtt to drop some unnecessary code from

Re: [Intel-gfx] [PATCH v2 8/8] drm/i915/gen9: Add WaOCLCoherentLineFlush

On 21/01/2016 14:00, Arun Siluvery wrote: This is mainly required for preemption. Cc: Dave Gordon Signed-off-by: Arun Siluvery Reviewed-by: Nick Hoath --- drivers/gpu/drm/i915/intel_ringbuffer.c | 4

[Intel-gfx] ✗ Fi.CI.BAT: warning for Pipe level color management

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test drv_module_reload_basic: pass -> DMESG-WARN (bsw-nuc-2) pass -> DMESG-WARN (skl-i5k-2) pass

Re: [Intel-gfx] [PATCH 01/25] drm/i915/fbc: wait for a vblank instead of 50ms when enabling

Op 19-01-16 om 14:35 schreef Paulo Zanoni: > Instead of waiting for 50ms, just wait until the next vblank, since > it's the minimum requirement. The whole infrastructure of FBC is based > on vblanks, so waiting for X vblanks instead of X milliseconds sounds > like the correct way to go. Besides,

Re: [Intel-gfx] [PATCH 00/25] FBC crtc/fb locking + smaller fixes

Op 19-01-16 om 14:35 schreef Paulo Zanoni: > Hi > > Here's yet another patch series randomly modifying the FBC code. We > start by refactoring things in order to fix the locking problems, then > fix a few other smaller problems and apply some polishing. > > Just to keep the tradition of the past

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915/skl: Enable Per context Preemption granularity control

On 21/01/2016 14:00, Arun Siluvery wrote: Per context preemption granularity control is only available from SKL:E0+ Cc: Dave Gordon Signed-off-by: Arun Siluvery Reviewed-by: Nick Hoath ---

[Intel-gfx] [PATCH i-g-t 0/4] New pipe level color management tests

Hi, This series enables testing pipe level color management using kernel patches from this serie : http://lists.freedesktop.org/archives/intel-gfx/2016-January/085922.html Most of the tests use pipe CRCs to check the results by comparing the output with the expected output drawn using cairo.

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Extract out gamma table and CSC to their own file

Hi Lionel, On 21 January 2016 at 15:03, Lionel Landwerlin wrote: > + /* Workaround : Do not read or write the pipe palette/gamma data while > +* GAMMA_MODE is configured for split gamma and IPS_CTL has IPS > enabled. > +*/ > + if

Re: [Intel-gfx] [RFC 6/9] drm/i915: Add sync framework support to execbuff IOCTL

Op 14-01-16 om 13:07 schreef Chris Wilson: > On Thu, Jan 14, 2016 at 11:47:17AM +, John Harrison wrote: >> On 13/01/2016 18:43, Chris Wilson wrote: >>> Use the upper s32 for the output, so again you are not overwriting user >>> state without good reason. >>> >> Makes sense. Will do. > It would

Re: [Intel-gfx] [RFC 6/9] drm/i915: Add sync framework support to execbuff IOCTL

On Thu, Jan 21, 2016 at 03:47:40PM +0100, Maarten Lankhorst wrote: > Op 14-01-16 om 13:07 schreef Chris Wilson: > > On Thu, Jan 14, 2016 at 11:47:17AM +, John Harrison wrote: > >> On 13/01/2016 18:43, Chris Wilson wrote: > >>> Use the upper s32 for the output, so again you are not overwriting

Re: [Intel-gfx] ✗ warning: Fi.CI.BAT

Hi, I got this message in reply to this patch (https://patchwork.freedesktop.org/patch/60736/). It looks like most of the warnings are related to 'PWM1 enabled' warnings that happen when the hardware is going into some power management state and BLM_PWM_ENABLE and/or BLM_PCH_PWM_ENABLE are

[Intel-gfx] [PATCH 6/6] drm/i915: Implement color management on chv

Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_drv.c| 3 + drivers/gpu/drm/i915/i915_reg.h| 40 +++ drivers/gpu/drm/i915/intel_color.c | 139 - 3 files changed, 180 insertions(+), 2 deletions(-)

[Intel-gfx] [PATCH 4/6] drm/i915: enable legacy palette for pipe C

Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_reg.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 63c4283..46143f8 100644 ---

[Intel-gfx] [PATCH 3/6] drm/i915: enable CSC for pipe C

Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_reg.h | 40 +++- 1 file changed, 27 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index

[Intel-gfx] [PATCH 1/6] drm/i915: Extract out gamma table and CSC to their own file

Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/intel_color.c | 174 +++ drivers/gpu/drm/i915/intel_display.c | 163 +++-

[Intel-gfx] [PATCH 0/6] Pipe level color management

Hi, This serie introduces pipe level color management through a set of properties attached to the CRTC. It also provides an implementation for some Intel platforms. This serie is based of a previous set of patches by Shashank Sharma and takes into account of the comments by Daniel Stone & Daniel

[Intel-gfx] ✗ Fi.CI.BAT: warning for Gen9 HW whitelist and Preemption WA patches (rev2)

== Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) bdw-nuci7total:140 pass:131 dwarn:0

[Intel-gfx] [PATCH i-g-t 1/4] lib: kms: add crtc_id to igt_pipe_t

Signed-off-by: Lionel Landwerlin --- lib/igt_kms.c | 1 + lib/igt_kms.h | 1 + 2 files changed, 2 insertions(+) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 497118a..f5eef82 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -1004,6 +1004,7 @@ void

[Intel-gfx] [PATCH i-g-t 2/4] lib: kms: add helpers for color management properties on pipes

Signed-off-by: Lionel Landwerlin --- lib/igt_kms.c | 74 +++ lib/igt_kms.h | 17 +- 2 files changed, 90 insertions(+), 1 deletion(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index

[Intel-gfx] [PATCH i-g-t 4/4] tests/kms_color: New test for pipe level color management

This test enables testing of : * degamma LUTs * csc matrix * gamma LUTs * legacy gamma LUTs Signed-off-by: Lionel Landwerlin --- tests/Makefile.sources | 1 + tests/kms_pipe_color.c | 986 + 2

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Gen9 HW whitelist and Preemption WA patches (rev2)

On 21/01/2016 14:25, Patchwork wrote: == Summary == Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly: 2016y-01m-21d-11h-02m-42s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) bdw-nuci7

Re: [Intel-gfx] [PATCH 7/8] drm/i915/skl: Enable Per context Preemption granularity control

On 13/01/2016 10:06, Arun Siluvery wrote: Per context preemption granularity control is only available from SKL:E0+ Cc: Dave Gordon Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 3 +++

Re: [Intel-gfx] [PATCH v2 0/8] Gen9 HW whitelist and Preemption WA patches

On Thu, Jan 21, 2016 at 02:00:39PM +, Arun Siluvery wrote: > Resending all patches as told by Daniel because I didn't use correct > message-id while replying updated version of Patch1 before which means > patchwork won't pickup and we won't have CI results. Previous updates > regarding Patch1

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915/bxt: Add GEN9_CS_DEBUG_MODE1 to HW whitelist

On 21/01/2016 14:00, Arun Siluvery wrote: Required for, WaDisableObjectLevelPreemptionForTrifanOrPolygon:bxt WaDisableObjectLevelPreemptionForInstancedDraw:bxt WaDisableObjectLevelPreemtionForInstanceId:bxt According to WA database these are only applicable for BXT:A0 but since A0 and A1 shares

[Intel-gfx] [PATCH 2/6] drm: introduce color correction properties

Signed-off-by: Lionel Landwerlin --- Documentation/DocBook/gpu.tmpl | 48 + drivers/gpu/drm/drm_atomic.c| 102 +++- drivers/gpu/drm/drm_atomic_helper.c | 10 drivers/gpu/drm/drm_crtc.c |

[Intel-gfx] [PATCH 5/6] drm/i915: Implement color management on bdw/skl/bxt/kbl

Signed-off-by: Lionel Landwerlin --- Documentation/DocBook/gpu.tmpl | 12 +- drivers/gpu/drm/i915/i915_drv.c | 24 ++- drivers/gpu/drm/i915/i915_drv.h | 9 + drivers/gpu/drm/i915/i915_reg.h | 22 +++ drivers/gpu/drm/i915/intel_color.c |

Re: [Intel-gfx] [PATCH 017/190] drm/i915: Remove forcewake dance from seqno/irq barrier on legacy gen6+

Dave Gordon writes: > On 11/01/16 09:16, Chris Wilson wrote: >> In order to ensure seqno/irq coherency, we current read a ring register. >> We are not sure quite how it works, only that is does. Experiments show >> that e.g. doing a clflush(seqno) instead is not

Re: [Intel-gfx] [PATCH 01/25] drm/i915/fbc: wait for a vblank instead of 50ms when enabling

Em Qui, 2016-01-21 às 15:17 +0100, Maarten Lankhorst escreveu: > Op 19-01-16 om 14:35 schreef Paulo Zanoni: > > Instead of waiting for 50ms, just wait until the next vblank, since > > it's the minimum requirement. The whole infrastructure of FBC is > > based > > on vblanks, so waiting for X

[Intel-gfx] [PATCH] drm/i915: Improve handling of overlapping objects

The generic interval tree we use to speed up range invalidation is an augmented rbtree that can report all overlapping intervals for a given range. Therefore we do not need to degrade to a linear list if we find overlapping objects. Oops. Signed-off-by: Chris Wilson Cc:

Re: [Intel-gfx] [PATCH v2 0/8] Gen9 HW whitelist and Preemption WA patches

On 21/01/2016 16:56, Chris Wilson wrote: On Thu, Jan 21, 2016 at 04:07:22PM +, Arun Siluvery wrote: On 21/01/2016 15:17, Chris Wilson wrote: On Thu, Jan 21, 2016 at 02:00:39PM +, Arun Siluvery wrote: Resending all patches as told by Daniel because I didn't use correct message-id while

Re: [Intel-gfx] [PATCH v2 0/8] Gen9 HW whitelist and Preemption WA patches

On 21/01/2016 15:17, Chris Wilson wrote: On Thu, Jan 21, 2016 at 02:00:39PM +, Arun Siluvery wrote: Resending all patches as told by Daniel because I didn't use correct message-id while replying updated version of Patch1 before which means patchwork won't pickup and we won't have CI

[Intel-gfx] [PATCH v2 0/2] Enabling GuC Loading on Broxton

This set of patches will enable the GuC loading for BXT. There is also a fix that is required for GuC submission with the BXT GuC to make it reliable. v2: Remove patch that is to be added with a later patchset. remove erroneous write (merge error) - Jeff McGee Peter Antoine (2): drm/i915:

[Intel-gfx] [PATCH v2 2/2] drm/i915: resize the GuC WOPCM for rc6

This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory spaces do not overlap. Issue: https://jira01.devtools.intel.com/browse/VIZ-6638 Signed-off-by: Peter Antoine --- drivers/gpu/drm/i915/i915_guc_reg.h | 3 ++-

[Intel-gfx] [PATCH v2 1/2] drm/i915: Adding Broxton GuC Loader Support

This commits adds the Broxton target to the GuC loader Issue: https://jira01.devtools.intel.com/browse/VIZ-6638 Signed-off-by: Peter Antoine --- drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_kms: Add COMIT_ATOMIC to igt_display_commit2()

On Fri, Jan 15, 2016 at 11:06:24AM +0200, Marius Vlad wrote: > So far, we had only COMMIT_UNIVERSAL and COMMIT_LEGACY, using > drmModeSetPlane()/drmSetCrtc(). This patch adds COMMIT_ATOMIC > to igt_display_commit2() that makes use of drmModeAtomicCommit(). > > Signed-off-by: Marius Vlad

Re: [Intel-gfx] A collection of cleanups

On 21/01/16 19:37, Dave Gordon wrote: Also includes Nick Hoath's patch to swap context/engine teardown. In-Reply-To: Hmm, editor/mailer seems to have dropped most of this summary :( Probably something to do with that IRT-line above ... what it was supposed to say was approximately this:

[Intel-gfx] [PATCH 01/25] drm/i915/fbc: wait for a vblank instead of 50ms when enabling

Instead of waiting for 50ms, just wait until the next vblank, since it's the minimum requirement. The whole infrastructure of FBC is based on vblanks, so waiting for X vblanks instead of X milliseconds sounds like the correct way to go. Besides, 50ms may be less than a vblank on super slow modes

[Intel-gfx] [PATCH 05/25] drm/i915/fbc: replace frequent dev_priv->fbc.x with fbc->x

We say "dev_priv->fbc.something" way too many times in our code while we could be saying just "fbc->something" with a previous declaration of fbc. This has been bothering me for a while but I didn't want to patch it since I wanted to fix the real problems first. But as I add more code I keep

Re: [Intel-gfx] [PATCH 1/4] drm/i915: PSR Fix standby logic for PSR on non DDI-A for certain platforms.

On Wed, 2016-01-20 at 14:11 +, Zanoni, Paulo R wrote: > Em Sex, 2015-12-11 às 08:39 -0800, Rodrigo Vivi escreveu: > > Current platforms that support PSR on other port than A only > > support > > link > > standby mode. > > > > The logic here was wrong since 'commit 89251b177b ("drm/i915: PSR:

[Intel-gfx] [PATCH 08/25] drm/i915/fbc: unconditionally update FBC during atomic commits

We unconditionally disable/update FBC even during the page flip IOCTLs, and an unconditional disable/update at every atomic commit touching the primary plane shouldn't impact PC state residency noticeably. Besides, the code that checks for rotation is a good hint that we may be forgetting

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for FBC crtc/fb locking + smaller fixes

Em Ter, 2016-01-19 às 14:50 +, Patchwork escreveu: > == Summary == > > Built on 20c388faff9d8c41ab27e825c685526561b892a2 drm-intel-nightly: > 2016y-01m-19d-13h-31m-46s UTC integration manifest > > Test kms_flip: > Subgroup basic-flip-vs-modeset: > pass   ->

Re: [Intel-gfx] [PATCH v2 0/8] Gen9 HW whitelist and Preemption WA patches

On Thu, Jan 21, 2016 at 04:07:22PM +, Arun Siluvery wrote: > On 21/01/2016 15:17, Chris Wilson wrote: > >On Thu, Jan 21, 2016 at 02:00:39PM +, Arun Siluvery wrote: > >>Resending all patches as told by Daniel because I didn't use correct > >>message-id while replying updated version of

  1   2   >