[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/skl: Fix (most) pipe underruns, properly this time (rev2)

== Series Details == Series: drm/i915/skl: Fix (most) pipe underruns, properly this time (rev2) URL : https://patchwork.freedesktop.org/series/10059/ State : failure == Summary == Applying: drm/i915/skl: Update plane watermarks atomically during plane updates fatal: sha1 information is

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [v3,1/3] drm: extra printk() wrapper macros

== Series Details == Series: series starting with [v3,1/3] drm: extra printk() wrapper macros URL : https://patchwork.freedesktop.org/series/10060/ State : failure == Summary == Series 10060v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/10060/revisions/1/mbox

Re: [Intel-gfx] [ANNOUNCE] 2016-Q2 release of KVMGT (Was Re: KVMGT - the implementation of ...)

Hi all, We are pleased to announce another update of Intel GVT-g for KVM. Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with mediated pass-through, starting from 5th generation Intel Core™ processors with Intel Graphics processors. A virtual GPU instance is

Re: [Intel-gfx] [PATCH 09/17] drm/i915: Debugfs support for GuC logging control

On 7/19/2016 4:54 PM, Tvrtko Ursulin wrote: On 10/07/16 14:41, akash.g...@intel.com wrote: From: Sagar Arun Kamble This patch provides debugfs interface i915_guc_output_control for on the fly enabling/disabling of logging in GuC firmware and controlling the

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Forcefully flush GuC log buffer on reset

On 7/19/2016 4:51 PM, Chris Wilson wrote: On Tue, Jul 19, 2016 at 12:12:20PM +0100, Tvrtko Ursulin wrote: On 10/07/16 14:41, akash.g...@intel.com wrote: From: Sagar Arun Kamble If GuC logs are being captured, there should be a force log buffer flush action sent

Re: [Intel-gfx] [PATCH 07/17] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

On 7/19/2016 5:01 PM, Tvrtko Ursulin wrote: On 10/07/16 14:41, akash.g...@intel.com wrote: From: Akash Goel Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the User to capture GuC firmware logs. Availed relay framework to implement the interface,

Re: [Intel-gfx] [PATCH 06/17] drm/i915: Handle log buffer flush interrupt event from GuC

On 7/19/2016 4:28 PM, Tvrtko Ursulin wrote: On 10/07/16 14:41, akash.g...@intel.com wrote: From: Sagar Arun Kamble GuC ukernel sends an interrupt to Host to flush the log buffer and expects Host to correspondingly update the read pointer information in the state

Re: [Intel-gfx] [PATCH 1/2] doc/sphinx: Enable keep_warnings

On Tue, 19 Jul 2016 13:42:54 +0200 Daniel Vetter wrote: > Unfortunately warnings generated after parsing in sphinx can end up > with entirely bogus files and line numbers as sources. Strangely for > outright errors this is not a problem. Trying to convert warnings to >

[Intel-gfx] [PATCH i-g-t] tools/intel_reg: enable quiet option for mmio

From: Clint Taylor Skip decode options and formatting when the quiet option is used during mmio reads. Makes intel_reg usable by scripts to return MMIO values. Signed-off-by: Clint Taylor --- tools/intel_reg.c | 7 ++- 1 file

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

Marc kicked me to the other side of the fence. I'm now cheering for the symbolic links back again. We cannot block users to use some new firmware version if they like/want/need.  Also, also as Chris highlighted the hardcoded version doesn't help the bisect but make it unlikely. I don't believe

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

Versioning dependencies isn't exactly a new problem outside the kernel, so please allow me to share my experience below. Thanks to Rodrigo for glancing over this email and preventing me from writing anything too stupid or that was said already. >> The firmware should be side-ways compatible for

Re: [Intel-gfx] [PATCH] drm/i915: Remove misleading CSR firmware loading docs

On Tue, Jul 19, 2016 at 07:43:56PM +0100, Dave Gordon wrote: > On 14/07/16 15:15, Daniel Vetter wrote: > > I forgot to remove these when reworking the firmware loading sequence > > last year. The new sequence is that we load firmware, and if it's not > > there we entirely (and permanently) fail

[Intel-gfx] [PATCH v2 1/2] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

Re: [Intel-gfx] [PATCH] drm/i915: Remove misleading CSR firmware loading docs

On 14/07/16 15:15, Daniel Vetter wrote: I forgot to remove these when reworking the firmware loading sequence last year. The new sequence is that we load firmware, and if it's not there we entirely (and permanently) fail dmc setup. Reported-by: Dave Gordon

Re: [Intel-gfx] [PATCH 12/13] drm/i915: Consolidate legacy semaphore initialization

On 15/07/16 14:13, Tvrtko Ursulin wrote: On 29/06/16 17:00, Chris Wilson wrote: On Wed, Jun 29, 2016 at 04:41:58PM +0100, Tvrtko Ursulin wrote: On 29/06/16 16:34, Chris Wilson wrote: On Wed, Jun 29, 2016 at 04:09:31PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/bxt: Fix performance due to bogus MOCS entry

On pe, 2016-07-01 at 14:54 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/bxt: Fix performance due to bogus MOCS entry > URL   : https://patchwork.freedesktop.org/series/9377/ > State : warning > > == Summary == > > Series 9377v1 drm/i915/bxt: Fix performance due to bogus

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Don't mark pipes as dirty unless we've added/removed pipes

On Tue, Jul 19, 2016 at 1:19 PM, Matt Roper wrote: > On Tue, Jul 19, 2016 at 12:30:56PM -0400, Lyude wrote: >> Now that we update the watermark values atomically, we still need to fix >> the case of how we update watermarks when we haven't added or removed >> pipes. >>

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Don't mark pipes as dirty unless we've added/removed pipes

On Tue, Jul 19, 2016 at 12:30:56PM -0400, Lyude wrote: > Now that we update the watermark values atomically, we still need to fix > the case of how we update watermarks when we haven't added or removed > pipes. > > When we haven't added or removed any pipes, we don't need to worry about > the ddb

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Update plane watermarks atomically during plane updates

On Tue, Jul 19, 2016 at 12:30:55PM -0400, Lyude wrote: > Thanks to Ville for suggesting this as a potential solution to pipe > underruns on Skylake. > > On Skylake all of the registers for configuring planes, including the > registers for configuring their watermarks, are double buffered. New >

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/skl: Fix (most) pipe underruns, properly this time

== Series Details == Series: drm/i915/skl: Fix (most) pipe underruns, properly this time URL : https://patchwork.freedesktop.org/series/10059/ State : failure == Summary == Applying: drm/i915/skl: Update plane watermarks atomically during plane updates fatal: sha1 information is lacking or

[Intel-gfx] ✓ Ro.CI.BAT: success for drm: drm_connector->s/connector_id/index/ for consistency (rev2)

== Series Details == Series: drm: drm_connector->s/connector_id/index/ for consistency (rev2) URL : https://patchwork.freedesktop.org/series/10029/ State : success == Summary == Series 10029v2 drm: drm_connector->s/connector_id/index/ for consistency

[Intel-gfx] [PATCH v3 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

Where we're going to continue regardless of the problem, rather than fail, then the message should be a WARNing rather than an ERROR. Signed-off-by: Dave Gordon Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_guc_submission.c | 18

[Intel-gfx] [PATCH v3 1/3] drm: extra printk() wrapper macros

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() provides several other useful intermediate levels such as NOTICE and WARNING. So this patch fills out the set by providing both regular and once-only macros for each of the levels INFO, NOTICE, and WARNING, using a common

[Intel-gfx] [PATCH v3 3/3] drm/i915/guc: revisit GuC loader message levels

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(), a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(), and one eliminated completely. v2: different permutation of levels :) v3: convert a couple of "this shouldn't happen" messages to WARN() [Tvrtko Ursulin].

[Intel-gfx] [PATCH 0/2] drm/i915/skl: Fix (most) pipe underruns, properly this time

Unfortunately as a few of you are aware, Skylake is still very prone to pipe underruns. Most of this comes from not doing things atomically enough (e.g. needing to ensure that we update watermarks with other plane attributes, not forcefully flushing pipes until we need to, etc.). Now that I've

[Intel-gfx] [PATCH 2/2] drm/i915/skl: Don't mark pipes as dirty unless we've added/removed pipes

Now that we update the watermark values atomically, we still need to fix the case of how we update watermarks when we haven't added or removed pipes. When we haven't added or removed any pipes, we don't need to worry about the ddb allocation changing. As such there's no order of flushing pipes we

[Intel-gfx] [PATCH 1/2] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[Intel-gfx] [PATCH] drm: drm_connector->s/connector_id/index/ for consistency

connector_id in the uapi actually means drm_connector->base.id, which is something entirely different. And ->index is also consistent with plane/encoder/CRTCS and the various drm_*_index() functions. While at it also improve/align the kerneldoc comment. v2: Mention where those ids are from ...

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

On Tue, Jul 19, 2016 at 04:50:49PM +0100, Chris Wilson wrote: > On Tue, Jul 19, 2016 at 06:25:42PM +0300, Ville Syrjälä wrote: > > On Tue, Jul 19, 2016 at 05:14:23PM +0200, Maarten Lankhorst wrote: > > > num_levels should be level+1, not level, else num_levels - 1 becomes > > > negative. This

Re: [Intel-gfx] [CI-RESEND 3/3] drm/i915/guc: revisit GuC loader message levels

On 19/07/16 15:26, Tvrtko Ursulin wrote: On 19/07/16 13:20, Dave Gordon wrote: Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(), a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(), and one eliminated completely. v2: different permutation of levels :) Signed-off-by: Dave

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

On Tue, Jul 19, 2016 at 06:25:42PM +0300, Ville Syrjälä wrote: > On Tue, Jul 19, 2016 at 05:14:23PM +0200, Maarten Lankhorst wrote: > > num_levels should be level+1, not level, else num_levels - 1 becomes > > negative. This resulted in bogus watermarks being written to the first > > 255 levels

Re: [Intel-gfx] [PATCH 1/2] doc/sphinx: Enable keep_warnings

On Tue, Jul 19, 2016 at 5:25 PM, Daniel Vetter wrote: > On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser > wrote: >> >> Am 19.07.2016 um 13:42 schrieb Daniel Vetter : >> >>> Unfortunately warnings generated after parsing in

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

On Tue, Jul 19, 2016 at 05:14:23PM +0200, Maarten Lankhorst wrote: > num_levels should be level+1, not level, else num_levels - 1 becomes > negative. This resulted in bogus watermarks being written to the first > 255 levels like below: > > [drm] Setting FIFO watermarks - C: plane=0, cursor=0,

Re: [Intel-gfx] [PATCH 1/2] doc/sphinx: Enable keep_warnings

On Tue, Jul 19, 2016 at 4:59 PM, Markus Heiser wrote: > > Am 19.07.2016 um 13:42 schrieb Daniel Vetter : > >> Unfortunately warnings generated after parsing in sphinx can end up >> with entirely bogus files and line numbers as sources. Strangely

[Intel-gfx] [PATCH] drm/i915/vlv: Fix off-by-1 error in calculating num_levels.

num_levels should be level+1, not level, else num_levels - 1 becomes negative. This resulted in bogus watermarks being written to the first 255 levels like below: [drm] Setting FIFO watermarks - C: plane=0, cursor=0, sprite0=0, sprite1=0, SR: plane=0, cursor=0 level=255 cxsr=0

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: use a separate GuC client for each engine

On 19/07/16 16:02, Tvrtko Ursulin wrote: On 19/07/16 13:59, Dave Gordon wrote: When using a single GuC client for multiple engines, the i915 driver has to merge all work items into a single work queue, which the GuC firmware then demultiplexes into separate submission queues per engine. In

Re: [Intel-gfx] [PATCH 5/5] drm/i915/guc: use for_each_engine_id() where appropriate

On 19/07/16 13:59, Dave Gordon wrote: Now that host structures are indexed by host engine-id rather than guc_id, we can usefully convert some for_each_engine() loops to use for_each_engine_id() and avoid multiple dereferences of engine->id. Also a few related tweaks to cache structure members

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: use a separate GuC client for each engine

On 19/07/16 13:59, Dave Gordon wrote: When using a single GuC client for multiple engines, the i915 driver has to merge all work items into a single work queue, which the GuC firmware then demultiplexes into separate submission queues per engine. In theory, this could lead to the single queue

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/5] drm/i915/guc: doorbell reset should avoid used doorbells

On 19/07/16 15:16, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915/guc: doorbell reset should avoid used doorbells URL : https://patchwork.freedesktop.org/series/10040/ State : failure == Summary == Series 10040v1 Series without cover letter

Re: [Intel-gfx] [PATCH 4/5] drm/i915/guc: add engine mask to GuC client & pass to GuC

On 19/07/16 13:59, Dave Gordon wrote: The Context Descriptor passed by the kernel to the GuC contains a field specifying which engine(s) the context will use. Historically, this was always set to "all of them", but now that we have one client per engine, we can be more precise, and set only the

Re: [Intel-gfx] [PATCH 2/5] drm/i915/guc: refactor guc_init_doorbell_hw()

On 19/07/16 13:59, Dave Gordon wrote: Commit message missing! :) Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 54 +- 1 file changed, 30 insertions(+), 24 deletions(-) diff --git

Re: [Intel-gfx] [PATCH 1/5] drm/i915/guc: doorbell reset should avoid used doorbells

On 19/07/16 13:59, Dave Gordon wrote: guc_init_doorbell_hw() borrows the (currently single) GuC client to use in reinitialising ALL the doorbell registers (as the hardware doesn't reset them when the GuC is reset). As a prerequisite for accommodating multiple clients, it should only reset

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [CI-RESEND,1/3] drm: extra printk() wrapper macros

On 19/07/16 14:53, Patchwork wrote: == Series Details == Series: series starting with [CI-RESEND,1/3] drm: extra printk() wrapper macros URL : https://patchwork.freedesktop.org/series/10036/ State : success == Summary == Series 10036v1 Series without cover letter

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Wait on external rendering for GEM objects

On Tue, Jul 19, 2016 at 05:12:22PM +0300, Joonas Lahtinen wrote: > On ti, 2016-07-19 at 11:51 +0100, Chris Wilson wrote: > > + resv = i915_gem_object_get_dmabuf_resv(obj); > > + if (resv) { > > + long err; > > We already have ret in the function scope. ret is int, we need a long.

Re: [Intel-gfx] [PATCH] drm/i915: Handle ENOSPC after failing to insert a mappable node

On Tue, Jul 19, 2016 at 09:28:34AM +0100, Chris Wilson wrote: > On Tue, Jul 19, 2016 at 08:55:55AM +0200, Daniel Vetter wrote: > > On Sat, Jul 16, 2016 at 06:42:36PM +0100, Chris Wilson wrote: > > > Even after adding individual page support for GTT mmaping, we can still > > > fail to find any

Re: [Intel-gfx] [PATCH i-g-t] tests: make color management tests part of the BAT

On Tue, Jul 19, 2016 at 12:42:36PM +0100, Chris Wilson wrote: > On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote: > > On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote: > > > Signed-off-by: Lionel Landwerlin > > > > Do we have the time

Re: [Intel-gfx] [CI-RESEND 3/3] drm/i915/guc: revisit GuC loader message levels

On 19/07/16 13:20, Dave Gordon wrote: Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(), a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(), and one eliminated completely. v2: different permutation of levels :) Signed-off-by: Dave Gordon ---

Re: [Intel-gfx] [PATCH v2] i915: fix build error with -Werror

On 19/07/16 08:05, Daniel Vetter wrote: On Mon, Jul 04, 2016 at 11:30:06AM -0400, Jeff Mahoney wrote: This fixes the following build error with -Werror and gcc 6.1: drivers/gpu/drm/i915/i915_debugfs.c:2103:6: error: suggest explicit braces to avoid ambiguous 'else' [-Werror=parentheses]

Re: [Intel-gfx] [CI-RESEND 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

On 19/07/16 13:20, Dave Gordon wrote: Where we're going to continue regardless of the problem, rather than fail, then the message should be a WARNing rather than an ERROR. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 18

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/5] drm/i915/guc: doorbell reset should avoid used doorbells

== Series Details == Series: series starting with [1/5] drm/i915/guc: doorbell reset should avoid used doorbells URL : https://patchwork.freedesktop.org/series/10040/ State : failure == Summary == Series 10040v1 Series without cover letter

Re: [Intel-gfx] [PATCH 8/8] drm/i915: Wait on external rendering for GEM objects

On ti, 2016-07-19 at 11:51 +0100, Chris Wilson wrote: > When transitioning to the GTT or CPU domain we wait on all rendering > from i915 to complete (with the optimisation of allowing concurrent read > access by both the GPU and client). We don't yet ensure all rendering > from third parties

Re: [Intel-gfx] [PATCH i-g-t v2 03/15] kms_psr_sink_crc: Use for_each_pipe_with_valid_output to find a valid config.

On Fri, 2016-07-15 at 14:15 +0300, Ander Conselvan De Oliveira wrote: > On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote: > > > > This is the only time PIPE_ANY was used to mean something other than > > unassign this output from a pipe. Without this PIPE_ANY can be aliased > > to

[Intel-gfx] [PATCH i-g-t] tests: add some color management tests to BAT

We only enable pipe A tests and basic size fuzzing tests to minimize the amount of time spend. From experience color management issues tends to trigger failures on all pipes so only testing one seems reasonable. Signed-off-by: Lionel Landwerlin ---

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [CI-RESEND,1/3] drm: extra printk() wrapper macros

== Series Details == Series: series starting with [CI-RESEND,1/3] drm: extra printk() wrapper macros URL : https://patchwork.freedesktop.org/series/10036/ State : success == Summary == Series 10036v1 Series without cover letter

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Mark imported dma-buf objects as being coherent

On ti, 2016-07-19 at 11:51 +0100, Chris Wilson wrote: > A foreign dma-buf does not share our cache domain tracking, and we rely > on the producer ensuring cache coherency. Marking them as being in the > CPU domain is incorrect. > > Signed-off-by: Chris Wilson Maybe

Re: [Intel-gfx] [PATCH i-g-t] tests: make color management tests part of the BAT

On 19/07/16 13:49, Chris Wilson wrote: On Tue, Jul 19, 2016 at 01:21:23PM +0100, Lionel Landwerlin wrote: On 19/07/16 12:42, Chris Wilson wrote: On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote: On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote: Signed-off-by:

[Intel-gfx] [PATCH 5/5] drm/i915/guc: use for_each_engine_id() where appropriate

Now that host structures are indexed by host engine-id rather than guc_id, we can usefully convert some for_each_engine() loops to use for_each_engine_id() and avoid multiple dereferences of engine->id. Also a few related tweaks to cache structure members locally wherever they're used more than

[Intel-gfx] [PATCH 3/5] drm/i915/guc: use a separate GuC client for each engine

When using a single GuC client for multiple engines, the i915 driver has to merge all work items into a single work queue, which the GuC firmware then demultiplexes into separate submission queues per engine. In theory, this could lead to the single queue becoming a bottleneck in which an excess

[Intel-gfx] [PATCH 4/5] drm/i915/guc: add engine mask to GuC client & pass to GuC

The Context Descriptor passed by the kernel to the GuC contains a field specifying which engine(s) the context will use. Historically, this was always set to "all of them", but now that we have one client per engine, we can be more precise, and set only the single bit for the engine that the

[Intel-gfx] [PATCH 2/5] drm/i915/guc: refactor guc_init_doorbell_hw()

Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 54 +- 1 file changed, 30 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index

[Intel-gfx] [PATCH 1/5] drm/i915/guc: doorbell reset should avoid used doorbells

guc_init_doorbell_hw() borrows the (currently single) GuC client to use in reinitialising ALL the doorbell registers (as the hardware doesn't reset them when the GuC is reset). As a prerequisite for accommodating multiple clients, it should only reset doorbells that are supposed to be disabled,

Re: [Intel-gfx] [PATCH i-g-t v2 01/15] igt_kms: Remove kmstest_connector_config.crtc_idx

Hey, Op 13-07-16 om 14:13 schreef Daniel Vetter: > On Wed, Jul 06, 2016 at 11:55:41AM +0200, Maarten Lankhorst wrote: >> This is the same as using config.pipe because the order of crtcs will >> never change. >> >> Signed-off-by: Maarten Lankhorst > In the

[Intel-gfx] [PATCH] drm: drm_connector->s/connector_id/index/ for consistency

connector_id in the uapi actually means drm_connector->base.id, which is something entirely different. And ->index is also consistent with plane/encoder/CRTCS and the various drm_*_index() functions. While at it also improve/align the kerneldoc comment. v2: Mention where those ids are from ...

Re: [Intel-gfx] [PATCH i-g-t] tests: make color management tests part of the BAT

On Tue, Jul 19, 2016 at 01:21:23PM +0100, Lionel Landwerlin wrote: > On 19/07/16 12:42, Chris Wilson wrote: > >On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote: > >>On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote: > >>>Signed-off-by: Lionel Landwerlin

Re: [Intel-gfx] [PATCH 2/2] drm/doc: Fix more kerneldoc/sphinx warnings

On Tue, Jul 19, 2016 at 01:42:55PM +0200, Daniel Vetter wrote: > These are the leftovers I could only track down using keep_warnings = > True. For some of them we might want to update our style guide on how > to reference structures and constants, not sure ... > > Cc: Markus Heiser

Re: [Intel-gfx] [PATCH i-g-t] tests: make color management tests part of the BAT

On 19/07/16 12:42, Chris Wilson wrote: On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote: On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote: Signed-off-by: Lionel Landwerlin Do we have the time for those in the BAT budget? Do we

[Intel-gfx] [CI-RESEND 2/3] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

Where we're going to continue regardless of the problem, rather than fail, then the message should be a WARNing rather than an ERROR. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++--- 1 file changed, 7 insertions(+), 11

[Intel-gfx] [CI-RESEND 3/3] drm/i915/guc: revisit GuC loader message levels

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(), a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(), and one eliminated completely. v2: different permutation of levels :) Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/intel_guc_loader.c | 34

[Intel-gfx] [CI-RESEND 1/3] drm: extra printk() wrapper macros

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() provides several other useful intermediate levels such as NOTICE and WARNING. So this patch fills out the set by providing both regular and once-only macros for each of the levels INFO, NOTICE, and WARNING, using a common

Re: [Intel-gfx] [PATCH] drm: drm_connector->s/connector_id/index/ for consistency

On Tue, Jul 19, 2016 at 12:57:52PM +0200, Daniel Vetter wrote: > connector_id in the uapi actually means drm_connector->base.id, which > is something entirely different. And ->index is also consistent with > plane/encoder/CRTCS and the various drm_*_index() functions. > > While at it also

Re: [Intel-gfx] [PATCH] drm: drm_connector->s/connector_id/index/ for consistency

On Tue, Jul 19, 2016 at 12:57:52PM +0200, Daniel Vetter wrote: > connector_id in the uapi actually means drm_connector->base.id, which > is something entirely different. And ->index is also consistent with > plane/encoder/CRTCS and the various drm_*_index() functions. > > While at it also

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] doc/sphinx: Enable keep_warnings

== Series Details == Series: series starting with [1/2] doc/sphinx: Enable keep_warnings URL : https://patchwork.freedesktop.org/series/10033/ State : failure == Summary == Applying: doc/sphinx: Enable keep_warnings Applying: drm/doc: Fix more kerneldoc/sphinx warnings fatal: sha1 information

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm: drm_connector->s/connector_id/index/ for consistency

== Series Details == Series: drm: drm_connector->s/connector_id/index/ for consistency URL : https://patchwork.freedesktop.org/series/10029/ State : failure == Summary == Series 10029v1 drm: drm_connector->s/connector_id/index/ for consistency

Re: [Intel-gfx] [PATCH i-g-t] tests: make color management tests part of the BAT

On Tue, Jul 19, 2016 at 08:48:11AM +0200, Daniel Vetter wrote: > On Fri, Jul 15, 2016 at 03:00:59PM +0100, Lionel Landwerlin wrote: > > Signed-off-by: Lionel Landwerlin > > Do we have the time for those in the BAT budget? Do we not? It has been demonstrated that

[Intel-gfx] [PATCH 1/2] doc/sphinx: Enable keep_warnings

Unfortunately warnings generated after parsing in sphinx can end up with entirely bogus files and line numbers as sources. Strangely for outright errors this is not a problem. Trying to convert warnings to errors also doesn't fix it. The only way to get useful output out of sphinx to be able to

[Intel-gfx] [PATCH 2/2] drm/doc: Fix more kerneldoc/sphinx warnings

These are the leftovers I could only track down using keep_warnings = True. For some of them we might want to update our style guide on how to reference structures and constants, not sure ... Cc: Markus Heiser Cc: Jonathan Corbet Cc:

Re: [Intel-gfx] [PATCH 07/17] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

On 10/07/16 14:41, akash.g...@intel.com wrote: From: Akash Goel Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the User to capture GuC firmware logs. Availed relay framework to implement the interface, where Driver will have to just use a relay API to

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/8] drm/i915: Move GEM request routines to i915_gem_request.c

== Series Details == Series: series starting with [1/8] drm/i915: Move GEM request routines to i915_gem_request.c URL : https://patchwork.freedesktop.org/series/10028/ State : failure == Summary == Series 10028v1 Series without cover letter

Re: [Intel-gfx] [PATCH 09/17] drm/i915: Debugfs support for GuC logging control

On 10/07/16 14:41, akash.g...@intel.com wrote: From: Sagar Arun Kamble This patch provides debugfs interface i915_guc_output_control for on the fly enabling/disabling of logging in GuC firmware and controlling the verbosity level of logs. The value written to the

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Forcefully flush GuC log buffer on reset

On Tue, Jul 19, 2016 at 12:12:20PM +0100, Tvrtko Ursulin wrote: > > On 10/07/16 14:41, akash.g...@intel.com wrote: > >From: Sagar Arun Kamble > > > >If GuC logs are being captured, there should be a force log buffer flush > >action sent to GuC before proceeding with GPU

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Forcefully flush GuC log buffer on reset

On 10/07/16 14:41, akash.g...@intel.com wrote: From: Sagar Arun Kamble If GuC logs are being captured, there should be a force log buffer flush action sent to GuC before proceeding with GPU reset and re-initializing GUC. Those logs would be useful to understand why

Re: [Intel-gfx] [PATCH 06/17] drm/i915: Handle log buffer flush interrupt event from GuC

On 10/07/16 14:41, akash.g...@intel.com wrote: From: Sagar Arun Kamble GuC ukernel sends an interrupt to Host to flush the log buffer and expects Host to correspondingly update the read pointer information in the state structure, once it has consumed the log buffer

[Intel-gfx] [PATCH] drm: drm_connector->s/connector_id/index/ for consistency

connector_id in the uapi actually means drm_connector->base.id, which is something entirely different. And ->index is also consistent with plane/encoder/CRTCS and the various drm_*_index() functions. While at it also improve/align the kerneldoc comment. v2: Mention where those ids are from ...

[Intel-gfx] [PATCH 7/8] drm/i915: Mark imported dma-buf objects as being coherent

A foreign dma-buf does not share our cache domain tracking, and we rely on the producer ensuring cache coherency. Marking them as being in the CPU domain is incorrect. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 ++ 1 file changed, 2

[Intel-gfx] [PATCH 8/8] drm/i915: Wait on external rendering for GEM objects

When transitioning to the GTT or CPU domain we wait on all rendering from i915 to complete (with the optimisation of allowing concurrent read access by both the GPU and client). We don't yet ensure all rendering from third parties (tracked by implicit fences on the dma-buf) is complete. Since

[Intel-gfx] [PATCH 3/8] drm/i915: Mark all current requests as complete before resetting them

Following a GPU reset upon hang, we retire all the requests and then mark them all as complete. If we mark them as complete first, we both keep the normal retirement order (completed first then retired) and provide a small optimisation for concurrent lookups. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 2/8] drm/i915: Retire oldest completed request before allocating next

In order to keep the memory allocated for requests reasonably tight, try to reuse the oldest request (so long as it is completed and has no external references) for the next allocation. v2: Throw in a comment to hopefully make sure no one mistakes the optimistic retirement of the oldest request

[Intel-gfx] [PATCH 5/8] drm/i915: Disable waitboosting for fence_wait()

We want to restrict waitboosting to known process contexts, where we can track which clients are receiving waitboosts and prevent excessive power wasting. For fence_wait() we do not have any client tracking and so that leaves it open to abuse. v2: Hide the IS_ERR_OR_NULL testing for special

[Intel-gfx] [PATCH 6/8] drm/i915: Disable waitboosting for mmioflips/semaphores

Since commit a6f766f39751 ("drm/i915: Limit ring synchronisation (sw sempahores) RPS boosts") and commit bcafc4e38b6a ("drm/i915: Limit mmio flip RPS boosts") we have limited the waitboosting for semaphores and flips. Ideally we do not want to boost in either of these instances as no userspace

[Intel-gfx] [PATCH 4/8] drm/i915: Derive GEM requests from dma-fence

dma-buf provides a generic fence class for interoperation between drivers. Internally we use the request structure as a fence, and so with only a little bit of interfacing we can rebase those requests on top of dma-buf fences. This will allow us, in the future, to pass those fences back to

[Intel-gfx] [PATCH 1/8] drm/i915: Move GEM request routines to i915_gem_request.c

Migrate the request operations out of the main body of i915_gem.c and into their own C file for easier expansion. v2: Move __i915_add_request() across as well Signed-off-by: Chris Wilson Acked-by: Mika Kuoppala Reviewed-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH] drm/i915: Use SSE4.1 movntdqa to accelerate reads from WC memory

On 18/07/16 16:06, Tvrtko Ursulin wrote: On 18/07/16 14:46, Tvrtko Ursulin wrote: [snip] This version generates the smallest code: static void __memcpy_ntdqa(struct qw2 *dst, const struct qw2 *src, unsigned long len) { unsigned long l4; kernel_fpu_begin(); l4 =

[Intel-gfx] [I-G-T] igt/gem_mocs_settings: improve RC6 testings

On some platforms the MOCS values are not always saved and restored on RC6 enter/exit. The rational is that the context with restore these values. On these platforms the test will fail as it tests the values by directly reading the MOCS registers. So this change removes the direct testing of the

Re: [Intel-gfx] [PATCH] drm/i915:gen9: restrict WaC6DisallowByGfxPause

Tim Gore  Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ > -Original Message- > From: Kamble, Sagar A > Sent: Tuesday, July 19, 2016 7:56 AM > To: Gore, Tim > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915:gen9: restrict >

Re: [Intel-gfx] [PATCH 01/11] drm/drm-kms.rst: Remove unused drm_fourcc.h include directive

On Fri, Jul 15, 2016 at 09:47:58PM +0200, Daniel Vetter wrote: > Right now there's nothing, and kernel-doc produces a warning because > of that. Remove it until we need it for a clean build. > > Cc: Laurent Pinchart > Signed-off-by: Daniel Vetter

Re: [Intel-gfx] [PATCH] drm/i915: Handle ENOSPC after failing to insert a mappable node

On Tue, Jul 19, 2016 at 08:55:55AM +0200, Daniel Vetter wrote: > On Sat, Jul 16, 2016 at 06:42:36PM +0100, Chris Wilson wrote: > > Even after adding individual page support for GTT mmaping, we can still > > fail to find any space within the mappable region, and > > drm_mm_insert_node() will then

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Simplify shrinker_lock

== Series Details == Series: drm/i915: Simplify shrinker_lock URL : https://patchwork.freedesktop.org/series/10016/ State : failure == Summary == Series 10016v1 drm/i915: Simplify shrinker_lock http://patchwork.freedesktop.org/api/1.0/series/10016/revisions/1/mbox Test gem_exec_gttfill:

Re: [Intel-gfx] [PATCH 2/2] drm/i915: refactor eb_get_batch()

On Fri, Jul 15, 2016 at 09:03:40AM +0100, Dave Gordon wrote: > On 14/07/16 15:03, Chris Wilson wrote: > >On Thu, Jul 14, 2016 at 02:12:55PM +0100, Dave Gordon wrote: > >>On 13/07/16 13:44, Chris Wilson wrote: > >>>On Wed, Jul 13, 2016 at 02:38:16PM +0200, Daniel Vetter wrote: > On Thu, Jun 30,

Re: [Intel-gfx] [PATCH] drm/i915: Handle ENOSPC after failing to insert a mappable node

On Tue, Jul 19, 2016 at 08:55:55AM +0200, Daniel Vetter wrote: > On Sat, Jul 16, 2016 at 06:42:36PM +0100, Chris Wilson wrote: > > Even after adding individual page support for GTT mmaping, we can still > > fail to find any space within the mappable region, and > > drm_mm_insert_node() will then

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,resend,1/2] drm/i915: compile-time consistency check on __EXEC_OBJECT flags

On Fri, Jul 15, 2016 at 09:52:27AM +0100, Dave Gordon wrote: > On 15/07/16 09:15, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [CI,resend,1/2] drm/i915: compile-time > > consistency check on __EXEC_OBJECT flags > > URL :

  1   2   >