Re: [Intel-gfx] [PATCH 4/4] drm/i915: Update kerneldoc for intel_dpll_mgr.c

2016-05-22 Thread R, Durgadoss
> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Ander Conselvan de Oliveira > Sent: Friday, May 20, 2016 8:24 PM > To: intel-gfx@lists.freedesktop.org > Cc: Conselvan De Oliveira, Ander > Subject: [Intel-gfx] [PATCH 4/4] drm/i915: Upda

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Rename intel_shared_dpll_commit() to _swap_state()

2016-05-22 Thread R, Durgadoss
> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Ander Conselvan de Oliveira > Sent: Friday, May 20, 2016 8:24 PM > To: intel-gfx@lists.freedesktop.org > Cc: Conselvan De Oliveira, Ander > Subject: [Intel-gfx] [PATCH 2/4] drm/i915: Rena

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Introduce intel_release_shared_dpll()

2016-05-22 Thread R, Durgadoss
> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Ander Conselvan de Oliveira > Sent: Friday, May 20, 2016 8:24 PM > To: intel-gfx@lists.freedesktop.org > Cc: Conselvan De Oliveira, Ander > Subject: [Intel-gfx] [PATCH 1/4] drm/i915: Intr

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Rename intel_shared_dpll->mode_set() to prepare()

2016-05-22 Thread R, Durgadoss
> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Ander Conselvan de Oliveira > Sent: Friday, May 20, 2016 8:24 PM > To: intel-gfx@lists.freedesktop.org > Cc: Conselvan De Oliveira, Ander > Subject: [Intel-gfx] [PATCH 3/4] drm/i915: Re

Re: [Intel-gfx] [PATCH] drm/i915/ilk: Wait one vblank before enabling audio

2016-05-22 Thread Jani Nikula
On Sat, 21 May 2016, Lyude wrote: > We no longer call ilk_audio_codec_enable() while we have vblanks > disabled. As such, we can finally fix this and stop the occasional pipe > underruns I'm seeing on this Dell OptiPlex 990. > > Cc: sta...@vger.kernel.org Even if this were the right fix now, I'd

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

2016-05-22 Thread Stephen Rothwell
Hi all, After merging the drm-intel tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/gpu/drm/i915/i915_trace.h:10:0, from drivers/gpu/drm/i915/i915_drv.h:2735, from drivers/gpu/drm/i915/i915_drv.c:34: drivers/gp

[Intel-gfx] Updated drm-intel-testing

2016-05-22 Thread Daniel Vetter
Hi all, New -testing cycle with cool stuff: - cmd-parser support for direct reg->reg loads (Ken Graunke) - better handle DP++ smart dongles (Ville) - bxt guc fw loading support (Nick Hoathe) - remove a bunch of struct typedefs from dpll code (Ander) - tons of small work all over to avoid casting b

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/12] drm/i915/fbdev: Limit the global async-domain synchronization

2016-05-22 Thread Patchwork
== Series Details == Series: series starting with [01/12] drm/i915/fbdev: Limit the global async-domain synchronization URL : https://patchwork.freedesktop.org/series/7525/ State : failure == Summary == Series 7525v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/

[Intel-gfx] [PATCH 12/12] drm/i915: Show context objects in debugfs/i915_gem_objects

2016-05-22 Thread Chris Wilson
Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_debugfs.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 30cb26fe2fa9..3d14

[Intel-gfx] [PATCH 03/12] drm/i915: Apply lockdep annotations to i915_gem_context.c

2016-05-22 Thread Chris Wilson
Markup the functions that require the caller to hold struct_mutex with lockdep_assert_held(). In the hopefully not-too-distant future we will split the struct_mutex up, and in doing so we need to be sure that we know what it protects - here the lockdep annotations are invaluable. Signed-off-by: Ch

[Intel-gfx] [PATCH 10/12] drm/i915: Merge legacy+execlists context structs

2016-05-22 Thread Chris Wilson
struct intel_context contains two substructs, one for the legacy RCS and one for every execlists engine. Since legacy RCS is a subset of the execlists engine support, just combine the two substructs. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i9

[Intel-gfx] [PATCH 05/12] drm/i915: Rename i915_gem_context_reference/unreference()

2016-05-22 Thread Chris Wilson
As these are wrappers around kref_get/kref_put() it is preferable to follow the naming convention and use the same verb get/put in our wrapper names for manipulating a reference to the context. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_drv

[Intel-gfx] [PATCH 07/12] drm/i915: Move pinning of dev_priv->kernel_context into its creator

2016-05-22 Thread Chris Wilson
Rather than have every context ask "am I owned by the kernel? pin!", move that logic into the creator of the kernel context, in order to improve code comprehension. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_context.c | 52 +

[Intel-gfx] [PATCH 02/12] drm/i915: Rename struct intel_context

2016-05-22 Thread Chris Wilson
Our goal is to rename the anonymous per-engine struct beneath the current intel_context. However, after a lively debate resolving around the confusion between intel_context_engine and intel_engine_context, the realisation is that the two structs target different users. The outer struct is API / use

[Intel-gfx] [PATCH 01/12] drm/i915/fbdev: Limit the global async-domain synchronization

2016-05-22 Thread Chris Wilson
During cleanup we have to synchronise with the async task we are using to initialise and register our fbdev. Currently, we are using a full synchronisation on the global domain, but we can restrict this to just synchronising up to our task if we remember our cookie. v2: async_synchronize_cookie()

[Intel-gfx] [PATCH 04/12] drm/i915: Rename and inline i915_gem_context_get()

2016-05-22 Thread Chris Wilson
i915_gem_context_get() is a very simple wrapper around idr_find(), so simple that it would be smaller to do the lookup inline. Also we use the verb 'lookup' to return a pointer from a handle, freeing 'get' to imply obtaining a reference to the context. Signed-off-by: Chris Wilson Cc: Tvrtko Ursul

[Intel-gfx] [PATCH 11/12] drm/i915: Rearrange i915_gem_context

2016-05-22 Thread Chris Wilson
Pack the integers and related types together inside the struct. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_drv.h | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/

[Intel-gfx] [PATCH 09/12] drm/i915: Put the kernel_context in drm_i915_private next to its friends

2016-05-22 Thread Chris Wilson
Just move the kernel_context memboer of drm_i915_private next to the engines it is associated with. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_drv.h| 3 +-- drivers/gpu/drm/i915/i915_guc_submission.c | 5 +++-- 2 files changed,

[Intel-gfx] [PATCH 08/12] drm/i915: Show i915_gem_context owner in debugfs

2016-05-22 Thread Chris Wilson
Print the context's owner (via the pid under file_priv) under debugfs. Note that since this was originally introducing dev_priv->kernel_context, there are a couple of leftover minor chunks. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_debugf

[Intel-gfx] [PATCH 06/12] drm/i915: Name the inner most per-engine intel_context struct

2016-05-22 Thread Chris Wilson
We want to give a name to the currently anonymous per-engine struct inside the context, so that we can assign it to a local variable and save clumsy typing. The name we have chosen is intel_context as it reflects the HW facing portion of the context state (the logical context state, the registers,

[Intel-gfx] Unanswered bug report in the Vulkan Intel driver

2016-05-22 Thread Ronie Salgado
Hello, First sorry, for the potential double post in the two different mailing list. I was told in Phoronix to direct my complains here. One month ago I submitted a bug report with a workaround patch for a clear violation of the Vulkan spec ( https://bugs.freedesktop.org/show_bug.cgi?id=95034 ).