== Series Details ==
Series: drm/i915: Correctly handle limited range YCbCr data on VLV/CHV
URL : https://patchwork.freedesktop.org/series/10154/
State : failure
== Summary ==
Series 10154v1 drm/i915: Correctly handle limited range YCbCr data on VLV/CHV
http://patchwork.freedesktop.org/api/1.0
== Series Details ==
Series: drm/i915/guc: emit (drm) messages at the most appropriate level
URL : https://patchwork.freedesktop.org/series/10150/
State : failure
== Summary ==
Series 10150v1 drm/i915/guc: emit (drm) messages at the most appropriate level
http://patchwork.freedesktop.org/api/1
== Series Details ==
Series: drm/i915/guc: use one GuC client per GPU engine
URL : https://patchwork.freedesktop.org/series/10149/
State : success
== Summary ==
Series 10149v1 drm/i915/guc: use one GuC client per GPU engine
http://patchwork.freedesktop.org/api/1.0/series/10149/revisions/1/mbox
Hi all,
We are pleased to announce another update of Intel GVT-g for Xen.
Intel GVT-g is a full GPU virtualization solution with mediated pass-through,
starting from 4th generation Intel Core(TM) processors with Intel Graphics
processors. A virtual GPU instance is maintained for each VM, with p
== Series Details ==
Series: series starting with [1/9] drm/i915: Rename request
reference/unreference to get/put (rev2)
URL : https://patchwork.freedesktop.org/series/10081/
State : failure
== Summary ==
Applying: drm/i915: Rename request reference/unreference to get/put
Using index info to
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, July 21, 2016 9:40 PM
To: Antoine, Peter
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [I-G-T] igt/gem_mocs_settings: improve RC6 testings
On Tue, Jul 19, 2016 at 11:25:29AM +0100, Peter Antoine
On Thu, Jul 21, 2016 at 03:23:40PM -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
> va
On Thu, Jul 21, 2016 at 03:23:38PM -0400, Lyude wrote:
> Manual pipe flushes are only necessary in order to make sure that we prevent
> pipes with changed ddb allocations from overlapping from one another at
> any point in time. Additionally, forcing us to wait for the next vblank
> every time we h
On Tue, Jul 19, 2016 at 11:25:29AM +0100, Peter Antoine wrote:
> 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
This reverts commit b12e0ee2080c ("drm/i915: Enable RC6 immediately"),
as it was never meant to be sent anywhere other than the bug report for
experimentation.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 5 +-
drivers/gpu/drm/i915/i915_drv.h
This reverts commit b12e0ee2080c ("drm/i915: Enable RC6 immediately"),
as it was never meant to be sent anywhere other than the bug report for
experimentation.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 5 +-
drivers/gpu/drm/i915/i915_drv.h
Similar to how a vehicle will travel faster if you paint flames on it,
cleaning up this extra whitespace is guaranteed to provide additional
stability while updating watermark values.
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_pm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/driv
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
"ar
Manual pipe flushes are only necessary in order to make sure that we prevent
pipes with changed ddb allocations from overlapping from one another at
any point in time. Additionally, forcing us to wait for the next vblank
every time we have to update the watermark values because the cursor was
movin
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
o
To Sebastian Reichel:
I *think* I may have found the problem. Looked at
./scripts/get_maintainer.pl and apparently it's defaults aren't
actually expected to work well with `git send-email`. I've added
--norolestats and hopefully that should fix the issue. If the emai
From: Ville Syrjälä
Turns out the VLV/CHV fixed function sprite CSC expects full range
data as input. We've been feeding it limited range data to it all
along. To expand the data out to full range we'll use the color
correction registers (brightness, contrast, and saturation).
On CHV pipe B we w
On Thu, Jul 21, 2016 at 07:57:39AM +0100, Chris Wilson wrote:
> As the interrupt wakeup counter only increments when we have a waiter,
> before testing to see if that counter is unchanged we have to first
> check that we do expect it to change (i.e. we have a waiter).
>
> Signed-off-by: Chris Wils
On Thu, Jul 21, 2016 at 07:15:39PM +0100, 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
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 under
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()
Signed-off-by: Dave Gordon
Reviewed-b
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 +++---
1 file changed, 7 insertions(+), 1
A few adjustments to the messages emitted from the driver, promoting
or demoting them to the level most suited to the target audience as
well as the impact of the thing being reported.
Dave Gordon (3):
drm: extra printk() wrapper macros
drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_
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 on
As we're tweaking the GuC-related code in debugfs, we can
drop the now-used 'q_fail' and repack the structure.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 -
drivers/gpu/drm/i915/intel_guc.h| 6 ++
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/
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 client
We have essentially the same code in each of two different loops, so we
can refactor it into a little helper function.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 54 +-
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/dr
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 of
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, avo
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 of
On Thu, Jul 21, 2016 at 06:39:38PM +0100, Dave Gordon wrote:
> The exit path in intel_overlay_put_image_ioctl() first unlocks the
> struct_mutex, then drops its reference to 'new_bo' by calling
> i915_gem_object_put(). As it isn't holding the mutex at this point,
> this should be i915_gem_object_pu
On Thu, Jul 21, 2016 at 06:39:38PM +0100, Dave Gordon wrote:
> The exit path in intel_overlay_put_image_ioctl() first unlocks the
> struct_mutex, then drops its reference to 'new_bo' by calling
> i915_gem_object_put(). As it isn't holding the mutex at this point,
> this should be i915_gem_object_pu
The exit path in intel_overlay_put_image_ioctl() first unlocks the
struct_mutex, then drops its reference to 'new_bo' by calling
i915_gem_object_put(). As it isn't holding the mutex at this point,
this should be i915_gem_object_put_unlocked().
This was previously correct but got splatted in the re
On Thu, Jul 21, 2016 at 05:58:03PM +0100, Dave Gordon wrote:
> The exit path in intel_overlay_put_image_ioctl() first unlocks the
> struct_mutex, then drops its reference to 'new_bo' by calling
> i915_gem_object_put(). As it isn't holding the mutex at this point,
> this should be i915_gem_object_pu
On 21/07/16 11:38, Tvrtko Ursulin wrote:
On 20/07/16 22:07, Rodrigo Vivi wrote:
please kill this _ucode variation that is just a alias to guc instead
Not sure, it was added with a particular goal. Cc Dave in case he wants
to comment.
Regards,
Tvrtko
The comment is already in the source
Two things for this one:
1. I completely messed up the description on this patchset, this was for fixing
underruns on pipe disablement. I'm impressed I wrote up that whole description
without realizing that at all, lol.
2. This patch may not actually be necessary. On the original git branch I was
t
The exit path in intel_overlay_put_image_ioctl() first unlocks the
struct_mutex, then drops its reference to 'new_bo' by calling
i915_gem_object_put(). As it isn't holding the mutex at this point,
this should be i915_gem_object_put_unlocked().
This was previously correct but got splatted in the re
On Thu, Jul 21, 2016 at 3:50 AM, Tvrtko Ursulin
wrote:
>
> On 20/07/16 18:40, Carlos Santa wrote:
>>
>> Moving all GPU features to the platform struct definition allows for
>> - standard place when adding new features from new platforms
>> - possible to see supported features when
On Thu, Jul 21, 2016 at 05:27:06PM +0100, Chris Wilson wrote:
> On Thu, Jul 21, 2016 at 05:18:17PM +0300, Joonas Lahtinen wrote:
> > On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
> > > static const struct intel_renderstate_rodata *
> > > render_state_get_rodata(const int gen)
> > > {
> >
On Thu, Jul 21, 2016 at 05:18:17PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
> > static const struct intel_renderstate_rodata *
> > render_state_get_rodata(const int gen)
> > {
> > @@ -51,6 +60,7 @@ static int render_state_init(struct render_state *so,
On Thu, Jul 21, 2016 at 04:30:08PM +0100, Chris Wilson wrote:
> In the refactoring to stop the rpm refleak, the call to
> intel_disable_gt_powersave() was mistakenly dropped from
> i915_drm_suspend(). It is still required in order to set the rps.enabled
> flag back to false so that it will re-enabl
== Series Details ==
Series: drm/i915: Disable GT powersaving upon suspend
URL : https://patchwork.freedesktop.org/series/10137/
State : warning
== Summary ==
Series 10137v1 drm/i915: Disable GT powersaving upon suspend
http://patchwork.freedesktop.org/api/1.0/series/10137/revisions/1/mbox
Te
On Thu, Jul 21, 2016 at 02:59:23PM +0300, Joonas Lahtinen wrote:
> > @@ -4567,8 +4567,8 @@ int i915_gem_init(struct drm_device *dev)
> >
> > if (!i915.enable_execlists) {
> > dev_priv->gt.execbuf_submit = i915_gem_ringbuffer_submission;
> > - dev_priv->gt.cleanup_engine
In the refactoring to stop the rpm refleak, the call to
intel_disable_gt_powersave() was mistakenly dropped from
i915_drm_suspend(). It is still required in order to set the rps.enabled
flag back to false so that it will re-enabled upon resume.
Fixes: b7137e0cf1e5 ("drm/i915: Defer enabling rc6 ti
On Thu, Jul 21, 2016 at 02:46:01PM +0100, Tvrtko Ursulin wrote:
>
> On 21/07/16 14:31, Chris Wilson wrote:
> >Hmm. This was in intel_ringbuffer.c, at least I assumed so as this only
> >applies to legacy submission, for gen6-7.
>
> It uses the static intel_engines array since the dev_priv->engines
On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
> static const struct intel_renderstate_rodata *
> render_state_get_rodata(const int gen)
> {
> @@ -51,6 +60,7 @@ static int render_state_init(struct render_state *so,
> int ret;
>
> so->gen = INTEL_GEN(dev_priv);
> + so->gg
On Thu, Jul 21, 2016 at 04:39:58PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
> > if (so.aux_batch_size > 8) {
> > - ret = req->engine->dispatch_execbuffer(req,
> > - (so.ggtt_offset +
> > -
On Thu, Jul 21, 2016 at 04:55:00PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
> > As gen6_emit_request() only differs from i9xx_emit_request() when
> > semaphores are enabled, only use the specialised vfunc in that scenario.
> >
> > Signed-off-by: Chris W
On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
> If we rewrite the I915_WRITE_TAIL specialisation for the legacy
> ringbuffer as submitting the request onto the ringbuffer, we can unify
> the vfunc with both execlists and GuC in the next patch.
>
> Signed-off-by: Chris Wilson
> ---
> driv
On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
> As gen6_emit_request() only differs from i9xx_emit_request() when
> semaphores are enabled, only use the specialised vfunc in that scenario.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 18 --
On 21/07/16 13:31, Gore, Tim wrote:
-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
Sent: Wednesday, July 20, 2016 11:38 AM
To: Gore, Tim
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Ro.CI.BAT: failure for drm/i915:gen9: restrict
WaC6DisallowByGfxPause (rev
On 21/07/16 14:31, Chris Wilson wrote:
On Thu, Jul 21, 2016 at 02:16:22PM +0100, Tvrtko Ursulin wrote:
On 21/07/16 13:59, Chris Wilson wrote:
On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Static table wastes space for invalid combinations and
engines
On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
> Both the ->dispatch_execbuffer and ->emit_bb_start callbacks do exactly
> the same thing, add MI_BATCHBUFFER_START to the request's ringbuffer -
> we need only one vfunc.
>
Some ranting below,
Reviewed-by: Joonas Lahtinen
> Signed-off-by:
On ke, 2016-07-20 at 13:25 -0700, Rodrigo Vivi wrote:
> On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote:
> > Moving all GPU features to the platform struct definition allows for
> > - standard place when adding new features from new platforms
> > - possible to see supported fe
If you look back we did have both no-black listing (only required a
proper major version) and black listing before we ended up deciding
that we'll use white listing. The reasons for this were too many
obscure firmware issues, undocumented interoperability details between
firmware and the driver and
On Thu, Jul 21, 2016 at 02:16:22PM +0100, Tvrtko Ursulin wrote:
>
> On 21/07/16 13:59, Chris Wilson wrote:
> >On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Static table wastes space for invalid combinations and
> >>engines which are not supporte
On 21/07/16 12:56, Dave Gordon wrote:
On 21/07/16 10:31, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Static table wastes space for invalid combinations and
engines which are not supported by Gen6 (legacy semaphores).
Replace it with a function devised by Dave Gordon.
I have verified that it
On 21/07/16 14:16, Tvrtko Ursulin wrote:
[snip]
+{
+if (x == y)
+return -1;
+
+x = intel_engines[x].guc_id;
+y = intel_engines[y].guc_id;
hw_id.
Some guys named Chris and Dave removed it. ;D
I need to take this back, I was confusing two tables and some past
discussio
On Thu, Jul 21, 2016 at 04:07:59PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
> > - trace_i915_gem_ring_sync_to(*to_req, from, from_req);
> > - ret = to->semaphore.sync_to(*to_req, from, seqno);
> > + trace_i915_gem_ring_sync_
On 21/07/16 13:59, Chris Wilson wrote:
On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Static table wastes space for invalid combinations and
engines which are not supported by Gen6 (legacy semaphores).
Replace it with a function devised by Dave Gordon.
On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
> If is simpler and leads to more readable code through the callstack if
> the allocation returns the allocated struct through the return value.
>
> The importance of this is that it no longer looks like we accidentally
> allocate requests as s
On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Static table wastes space for invalid combinations and
> engines which are not supported by Gen6 (legacy semaphores).
>
> Replace it with a function devised by Dave Gordon.
>
> I have verified that it gen
== Series Details ==
Series: drm/i915: Replace gen6 semaphore signal table with code (rev3)
URL : https://patchwork.freedesktop.org/series/10129/
State : failure
== Summary ==
Series 10129v3 drm/i915: Replace gen6 semaphore signal table with code
http://patchwork.freedesktop.org/api/1.0/series
Op 21-07-16 om 14:13 schreef Ander Conselvan De Oliveira:
> On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
>> This will make it easier to support TEST_ONLY commits.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> lib/igt_kms.c | 84 ++-
Op 21-07-16 om 13:42 schreef Ander Conselvan De Oliveira:
> On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
>> They're duplicates with src_x/y, so just use those.
>>
>> Changes since v1:
>> - Fix order of parameters in calls to igt_fb_set_position.
>>
>> Signed-off-by: Maarten Lankhorst
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
> Sent: Wednesday, July 20, 2016 11:38 AM
> To: Gore, Tim
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Ro.CI.BAT
== Series Details ==
Series: drm/i915: Replace gen6 semaphore signal table with code (rev2)
URL : https://patchwork.freedesktop.org/series/10129/
State : failure
== Summary ==
Series 10129v2 drm/i915: Replace gen6 semaphore signal table with code
http://patchwork.freedesktop.org/api/1.0/series
On Thu, Jul 21, 2016 at 03:01:07PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote:
> > Now that we have a clear ring/engine split and a struct intel_ring, we
> > no longer need the stopgap ringbuf names.
> >
> > Signed-off-by: Chris Wilson
>
> Why is this a
On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
> This will make it easier to support TEST_ONLY commits.
>
> Signed-off-by: Maarten Lankhorst
> ---
> lib/igt_kms.c | 84 ++--
> ---
> 1 file changed, 48 insertions(+), 36 deletions(-)
On Thu, Jul 21, 2016 at 02:26:19PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote:
> > Both perform the same actions with more or less indirection, so just
> > unify the code.
> >
>
> Don't really like removing the engine = req->engine aliases, but seems
> li
On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote:
> For more consistent oop-naming, we would use intel_ring_verb, so pick
> intel_ring_pin() and intel_ring_unpin().
>
The done renames clearly here, then;
Reviewed-by: Joonas Lahtinen
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i
On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote:
> Now that we have a clear ring/engine split and a struct intel_ring, we
> no longer need the stopgap ringbuf names.
>
> Signed-off-by: Chris Wilson
Why is this a separate patch? List the renames here too, with those;
Reviewed-by: Joonas Lah
From: Tvrtko Ursulin
Static table wastes space for invalid combinations and
engines which are not supported by Gen6 (legacy semaphores).
Replace it with a function devised by Dave Gordon.
I have verified that it generates the same mappings between
mbox selectors and signalling registers.
v2: A
From: Tvrtko Ursulin
Static table wastes space for invalid combinations and
engines which are not supported by Gen6 (legacy semaphores).
Replace it with a function devised by Dave Gordon.
I have verified that it generates the same mappings between
mbox selectors and signalling registers.
v2: A
On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote:
> The state stored in this struct is not only the information about the
> buffer object, but the ring used to communicate with the hardware. Using
> buffer here is overly specific and, for me at least, conflates with the
> notion of buffer objec
On 21/07/16 10:31, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Static table wastes space for invalid combinations and
engines which are not supported by Gen6 (legacy semaphores).
Replace it with a function devised by Dave Gordon.
I have verified that it generates the same mappings between
mbox
On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote:
> Perform s/ringbuf/ring/ on the context struct for consistency with the
> ring/engine split.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_debugfs.c| 8
> drivers/gpu/drm/i915/i915_drv.h| 2
On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
> They're duplicates with src_x/y, so just use those.
>
> Changes since v1:
> - Fix order of parameters in calls to igt_fb_set_position.
>
> Signed-off-by: Maarten Lankhorst
> ---
> lib/igt_kms.c | 24 --
On Thu, Jul 21, 2016 at 02:32:52PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote:
> > Having ringbuf->ring point to an engine is confusing, so rename it once
> > again to ring->engine.
> >
>
> Commit message and content do not seem to match.
It does, but it
On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote:
> Having ringbuf->ring point to an engine is confusing, so rename it once
> again to ring->engine.
>
Commit message and content do not seem to match.
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 12 ++-
On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote:
> Both perform the same actions with more or less indirection, so just
> unify the code.
>
Don't really like removing the engine = req->engine aliases, but seems
like req->engine is used plenty already. And assuming this was a
mechanical chang
On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote:
> Now that we have disambuigated ring and engine, we can use the clearer
> and more consistent name for the intel_ringbuffer pointer in the
> request.
>
The cocci data would be useful, or sed expression. And would make me
more confident this i
On Thu, Jul 21, 2016 at 01:32:48PM +0300, Joonas Lahtinen wrote:
> Was not this implemented once and then dropped for some reason?
Dunno.
>
> On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Add "bad-rotation" subtest to make sure the kerne
On Thu, Jul 21, 2016 at 11:28:02AM +0100, Tvrtko Ursulin wrote:
>
> On 21/07/16 11:10, Chris Wilson wrote:
> >On Thu, Jul 21, 2016 at 10:58:05AM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 21/07/16 07:57, Chris Wilson wrote:
> >>>During the idle-worker we disable the hangcheck and so kick any waiters
On 20/07/16 18:40, Carlos Santa wrote:
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
--
On 20/07/16 22:07, Rodrigo Vivi wrote:
please kill this _ucode variation that is just a alias to guc instead
Not sure, it was added with a particular goal. Cc Dave in case he wants
to comment.
Regards,
Tvrtko
On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote:
Moving all GPU feat
Was not this implemented once and then dropped for some reason?
On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add "bad-rotation" subtest to make sure the kernel rejects some
> invalid rotation values (0 and specifying multiple angles at one).
>
On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The primary and sprite planes on CHV pipe B support horizontal
> mirroring. Expose it to the world.
>
> Sadly the hardware ignores the mirror bit when the rotate bit is
> set, so we'll have to reject
On 21/07/16 11:10, Chris Wilson wrote:
On Thu, Jul 21, 2016 at 10:58:05AM +0100, Tvrtko Ursulin wrote:
On 21/07/16 07:57, Chris Wilson wrote:
During the idle-worker we disable the hangcheck and so kick any waiters
that should have been completed (since the GPU is now idle). Unlike the
hangche
On Thu, Jul 21, 2016 at 10:31:35AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Static table wastes space for invalid combinations and
> engines which are not supported by Gen6 (legacy semaphores).
>
> Replace it with a function devised by Dave Gordon.
>
> I have verified that it gen
On Thu, Jul 21, 2016 at 10:58:05AM +0100, Tvrtko Ursulin wrote:
>
> On 21/07/16 07:57, Chris Wilson wrote:
> >During the idle-worker we disable the hangcheck and so kick any waiters
> >that should have been completed (since the GPU is now idle). Unlike the
> >hangcheck, we do not take any care to
On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
> Move properties to the pipe, they don't belong in the output
> and make atomic commit use the pipes for crtc properties.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveira
> ---
> lib/igt_kms.c | 98 +
== Series Details ==
Series: drm/i915: Replace gen6 semaphore signal table with code
URL : https://patchwork.freedesktop.org/series/10129/
State : failure
== Summary ==
Series 10129v1 drm/i915: Replace gen6 semaphore signal table with code
http://patchwork.freedesktop.org/api/1.0/series/10129/
On 21/07/16 07:57, Chris Wilson wrote:
During the idle-worker we disable the hangcheck and so kick any waiters
that should have been completed (since the GPU is now idle). Unlike the
hangcheck, we do not take any care to avoid the race between the irq
handler and ourselves, and so it is possible
On 21/07/16 07:18, Goel, Akash wrote:
On 7/21/2016 11:13 AM, Chris Wilson wrote:
On Thu, Jul 21, 2016 at 09:11:42AM +0530, Goel, Akash wrote:
On 7/21/2016 1:04 AM, Chris Wilson wrote:
In the end, just the silly locking and placement of complete_all() is
dangerous. reinit_completion() lacks
On 20/07/16 18:31, Chris Wilson wrote:
On Wed, Jul 20, 2016 at 06:16:07PM +0100, Dave Gordon wrote:
'ring' is an old deprecated term for a GPU engine, so we're trying to
phase out all such terminology. eb_select_ring() not only has 'ring'
(meaning engine) in its name, but it has an ugly calling
From: Tvrtko Ursulin
Static table wastes space for invalid combinations and
engines which are not supported by Gen6 (legacy semaphores).
Replace it with a function devised by Dave Gordon.
I have verified that it generates the same mappings between
mbox selectors and signalling registers.
Signe
On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
> None of the tests requires that a output bound to PIPE_ANY is assigned,
> so don't do it. Fix the display commit to iterate over crtc's instead
> of outputs to properly disable pipes without outputs.
>
> This also means that output->val
Op 20-07-16 om 14:56 schreef Ander Conselvan De Oliveira:
> On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote:
>> Use for_each_pipe_with_valid_output instead.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> tests/kms_crtc_background_color.c | 3 +--
>> tests/kms_flip_tiling.c
On Thu, Jul 21, 2016 at 05:49:32AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915: rename macro parameter(ring) to
> (engine)
> URL : https://patchwork.freedesktop.org/series/10101/
> State : success
Pick these up, just a few more stray rings lef
1 - 100 of 106 matches
Mail list logo
