> -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
> -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
> -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
> -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
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
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
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
== 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/
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
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
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
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
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 +
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
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()
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
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/
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,
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
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,
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 ).
21 matches
Mail list logo