On Thu, 14 Jan 2016, Francisco Jerez wrote:
> We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee
> that writes performed via the HDC are visible in memory. Fixes an
> intermittent failure in a Piglit test that writes to a BO from a
> shader using GL atomic counters (implemented as
== Summary ==
Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly:
2016y-01m-13d-17h-07m-44s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (bdw-nuci7)
dmesg-warn -> PASS (skl-i7k-2) UN
Nitpick, should have [maintainer-tools PATCH] in the subject.
On Wed, 13 Jan 2016, Daniel Vetter wrote:
> Also try to polish the formatting a bit.
>
> Signed-off-by: Daniel Vetter
> ---
> drm-intel.rst | 60
> ++-
> 1 file changed, 59 in
== Summary ==
Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly:
2016y-01m-13d-17h-07m-44s UTC integration manifest
Test gem_ctx_basic:
pass -> FAIL (bdw-ultra)
Test gem_ctx_param_basic:
Subgroup non-root-set:
pass -> DM
From: Chris Wilson
Ville reminded us that stolen memory is not preserved across
hibernation, and a result of this was that context objects now being
allocated from stolen were being corrupted on S4 and promptly hanging
the GPU on resume.
We want to utilise stolen for as much as possible (nothing
From: Ankitprasad Sharma
In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
we try a nonblocking pin for the whole object (since that is fastest if
reused), then failing that we try to grab one page in the mappable
aperture. It also allows us to handle objects larger than th
From: Chris Wilson
If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evicting
objects to free up enough contiguous space in the vma when bind
From: Ankitprasad Sharma
Some modules, like i915.ko, needs to detect when certain ACPI features
are active inorder to prevent corruption on contended resources.
In particular, use of BIOS RapidStart Technology may corrupt the contents
of the reserved graphics memory, due to unalarmed hibernation.
From: Ankitprasad Sharma
Extend the drm_i915_gem_create structure to add support for
creating Stolen memory backed objects. Added a new flag through
which user can specify the preference to allocate the object from
stolen memory, which if set, an attempt will be made to allocate
the object from s
From: Ankitprasad Sharma
The BIOS RapidStartTechnology may corrupt the stolen memory across S3
suspend due to unalarmed hibernation, in which case we will not be able
to preserve the User data stored in the stolen region. Hence this patch
tries to identify presence of the RST device on the ACPI b
From: Ankitprasad Sharma
This patch adds support for clearing buffer objects via CPU/GTT. This
is particularly useful for clearing out the non shmem backed objects.
Currently intend to use this only for buffers allocated from stolen
region.
v2: Added kernel doc for i915_gem_clear_object(), corre
From: Ankitprasad Sharma
This patch series adds support for creating/using Stolen memory backed
objects.
Despite being a unified memory architecture (UMA) some bits of memory
are more equal than others. In particular we have the thorny issue of
stolen memory, memory stolen from the system by the
From: Ankitprasad Sharma
This patch adds support for extending the pread/pwrite functionality
for objects not backed by shmem. The access will be made through
gtt interface. This will cover objects backed by stolen memory as well
as other non-shmem backed objects.
v2: Drop locks around slow_user
From: Ankitprasad Sharma
Propagating correct error codes to userspace by using ERR_PTR and
PTR_ERR macros for stolen memory based object allocation. We generally
return -ENOMEM to the user whenever there is a failure in object
allocation. This patch helps user to identify the correct reason for t
From: Chris Wilson
This utility function is a companion to i915_gem_object_get_page() that
uses the same cached iterator for the scatterlist to perform fast
sequential lookup of the dma address associated with any page within the
object.
Signed-off-by: Chris Wilson
Signed-off-by: Ankitprasad Sh
From: Chris Wilson
Introduced a new vm specfic callback insert_page() to program a single pte in
ggtt or ppgtt. This allows us to map a single page in to the mappable aperture
space. This can be iterated over to access the whole object by using space as
meagre as page size.
Signed-off-by: Chris
Tested-by: Mark Janes
Francisco Jerez writes:
> We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee
> that writes performed via the HDC are visible in memory. Fixes an
> intermittent failure in a Piglit test that writes to a BO from a
> shader using GL atomic counters (implement
On Wed, Jan 13, 2016 at 05:57:29PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The sync framework is now used by the i915 driver. Therefore it can be
> moved out of staging and into the regular tree. Also, the public
> interfaces can actually be made public and exported.
>
We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee
that writes performed via the HDC are visible in memory. Fixes an
intermittent failure in a Piglit test that writes to a BO from a
shader using GL atomic counters (implemented as HDC untyped atomics)
and then expects the memory to
Hi Daniel,
Thank you for the patch.
On Wednesday 13 January 2016 12:05:14 Daniel Vetter wrote:
> Again since the core takes care of this we can remove them. While at
> it also remove the postclose hook, it's empty.
>
> v2: Laurent pointed me at even more code to delete.
>
> v3: Remove unused fl
When we stop the sink CRC calculation we wait a while until the counter
is reset to zero and return -ETIMEDOUT. However the sink crc was
calculated already by this point so we just ignore this return at
the main function.
So, let's also ignore the message and put it as a debug message instead
of a
Also try to polish the formatting a bit.
Signed-off-by: Daniel Vetter
---
drm-intel.rst | 60 ++-
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/drm-intel.rst b/drm-intel.rst
index 12bceb4e5324..e5c54d3d64ed 100644
--- a/drm-
On Wed, Jan 13, 2016 at 05:28:15PM +, Arun Siluvery wrote:
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 8d90c25..5cf9c11 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -37,6 +37,8 @@ struct i
On Wed, Jan 13, 2016 at 05:28:15PM +, Arun Siluvery wrote:
> @@ -596,6 +598,16 @@ static int i915_drm_suspend(struct drm_device *dev)
> + atomic_clear_mask(I915_RESET_IN_PROGRESS_FLAG,
> + &dev_priv->gpu_error.reset_counter);
This could be its own little patch as we could appl
On Wed, Jan 13, 2016 at 05:28:19PM +, Arun Siluvery wrote:
> /* i915_irq.c */
> void i915_queue_hangcheck(struct drm_device *dev);
> -__printf(4, 5)
> -void i915_handle_error(struct drm_device *dev, u32 engine_mask, bool wedged,
> -const char *fmt, ...);
> +__printf(5, 6)
On Wed, Jan 13, 2016 at 05:28:18PM +, Arun Siluvery wrote:
> From: Tomas Elf
>
> There used to be a work queue separating the error handler from the hang
> recovery path, which was removed a while back in this commit:
>
> commit b8d24a06568368076ebd5a858a011699a97bfa42
> Author:
On Wed, Jan 13, 2016 at 05:28:17PM +, Arun Siluvery wrote:
> From: Tomas Elf
>
> i915_gem_wedge now returns a non-zero result in three different cases:
>
> 1. Legacy: A hang has been detected and full GPU reset is in progress.
>
> 2. Per-engine recovery:
>
> a. A single engine refere
On Wed, Jan 13, 2016 at 05:28:16PM +, Arun Siluvery wrote:
> From: Tomas Elf
>
> With the per-engine hang recovery path already in place this patch adds
> per-engine hang detection by letting the periodic hang checker detect hangs on
> individual engines and communicate this to the error hand
On Wed, Jan 13, 2016 at 06:46:08PM +, Dave Gordon wrote:
> On 13/01/16 13:41, Chris Wilson wrote:
> >On Wed, Jan 13, 2016 at 01:27:51PM +, Dave Gordon wrote:
> >>On 12/01/16 14:27, Chris Wilson wrote:
> >>>On Tue, Jan 12, 2016 at 01:56:48PM +, Chris Wilson wrote:
> But we were remov
On Tue, Jan 12, 2016 at 06:16:21PM +, Dave Gordon wrote:
> On 11/01/16 09:16, Chris Wilson wrote:
> >As we add the VMA to the request early, it may be cancelled during
> >execbuf reservation. This will leave the context object pointing to a
> >dangling request; i915_wait_request() simply skips
2016-01-13 john.c.harri...@intel.com :
> From: John Harrison
>
> The sync framework is now used by the i915 driver. Therefore it can be
> moved out of staging and into the regular tree. Also, the public
> interfaces can actually be made public and exported.
>
> v0.3: New patch for series.
>
>
On Wed, Jan 13, 2016 at 07:14:56PM +, Arun Siluvery wrote:
> On 13/01/2016 19:01, Chris Wilson wrote:
> >On Wed, Jan 13, 2016 at 03:38:15PM +, Arun Siluvery wrote:
> >>Some of the HW registers are privileged and cannot be written to from
> >>non-privileged batch buffers coming from userspac
On Wed, Jan 13, 2016 at 04:16:21PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> LRC code was calling GEM API like i915_gem_obj_ggtt_offset from
> places where the struct_mutex cannot be grabbed (irq handlers).
>
> To avoid that this patch caches some interesting bits and values
> in t
This version resolved the issue (kernel bug check in
intel_lr_context_clean_ring) I reported on previous versions. Verified
by igt drv_module_reload_basic, gem_close_race and -t basic tests.
Reviewed-by: Alex Dai
On 01/13/2016 08:19 AM, Nick Hoath wrote:
Use the first retired request on a ne
On 13/01/2016 19:01, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 03:38:15PM +, Arun Siluvery wrote:
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
On 13/01/16 19:01, yu@intel.com wrote:
From: Alex Dai
During driver unloading, the guc_client created for command submission
needs to be released to avoid memory leak.
The struct_mutex needs to be held before tearing down GuC.
v1: Move i915_guc_submission_disable out of i915_guc_submissio
On 12/01/16 23:49, Chris Wilson wrote:
On Tue, Jan 12, 2016 at 11:40:06PM +, Chris Wilson wrote:
struct drm_i915_gem_object_ops {
+ const unsigned int flags;
Bleh, const is redundant as the definitions should be const themselves.
-Chris
Yeah, the const-ness attaches to the instan
From: Alex Dai
During driver unloading, the guc_client created for command submission
needs to be released to avoid memory leak.
The struct_mutex needs to be held before tearing down GuC.
v1: Move i915_guc_submission_disable out of i915_guc_submission_fini and
take struct_mutex lock before
Hi John,
2016-01-13 john.c.harri...@intel.com :
> From: Maarten Lankhorst
>
> This allows users of dma fences to create a android fence.
>
> v0.2: Added kerneldoc. (Tvrtko Ursulin).
>
> v0.4: Updated comments from review feedback by Maarten.
>
> Signed-off-by: Maarten Lankhorst
> Signed-off
On Wed, Jan 13, 2016 at 03:38:15PM +, Arun Siluvery wrote:
> 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 w
Hi John,
2016-01-13 john.c.harri...@intel.com :
> From: John Harrison
>
> The sync framework is now used by the i915 driver. Therefore it can be
> moved out of staging and into the regular tree. Also, the public
> interfaces can actually be made public and exported.
I also have been working on
On 13/01/16 18:17, Yu Dai wrote:
On 01/13/2016 10:15 AM, Dave Gordon wrote:
On 12/01/16 23:17, yu@intel.com wrote:
> From: Alex Dai
>
> During driver unloading, the guc_client created for command submission
> needs to be released to avoid memory leak.
>
> The struct_mutex needs to be held
On 13/01/16 13:41, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 01:27:51PM +, Dave Gordon wrote:
On 12/01/16 14:27, Chris Wilson wrote:
On Tue, Jan 12, 2016 at 01:56:48PM +, Chris Wilson wrote:
But we were removing the engine->default_context as it complicated the
rest of the code. I st
On Wed, Jan 13, 2016 at 05:57:32PM +, john.c.harri...@intel.com wrote:
> static int
> i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> struct drm_file *file,
> @@ -1428,6 +1465,17 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
> u32 dis
On 01/13/2016 10:15 AM, Dave Gordon wrote:
On 12/01/16 23:17, yu@intel.com wrote:
> From: Alex Dai
>
> During driver unloading, the guc_client created for command submission
> needs to be released to avoid memory leak.
>
> The struct_mutex needs to be held before tearing down GuC.
>
> v1:
On 12/01/16 23:17, yu@intel.com wrote:
From: Alex Dai
During driver unloading, the guc_client created for command submission
needs to be released to avoid memory leak.
The struct_mutex needs to be held before tearing down GuC.
v1: Move i915_guc_submission_disable out of i915_guc_submissio
On Wed, Jan 13, 2016 at 05:17:03PM +0100, Daniel Vetter wrote:
> On Wed, Jan 13, 2016 at 03:13:40PM -, Patchwork wrote:
> > == Summary ==
> >
> > Built on 4d09810b01441f9124c072a866f608b748f92f6c drm-intel-nightly:
> > 2016y-01m-13d-12h-32m-08s UTC integration manifest
> >
> > Test gem_ctx_b
From: John Harrison
There is a sync framework to allow work for multiple independent
systems to be synchronised with each other but without stalling
the CPU whether in the application or the driver. This patch adds
support for this framework to the GPU scheduler.
Batch buffers can now have sync
From: John Harrison
Various projects desire a mechanism for managing dependencies between
work items asynchronously. This can also include work items across
complete different and independent systems. For example, an
application wants to retrieve a frame from a video in device,
using it for rende
From: Peter Lawthers
In the 3.14 kernel, a signaled fence was indicated by the status field
== 1. In 4.x, a status == 0 indicates signaled, status < 0 indicates error,
and status > 0 indicates active.
This patch wraps the check for a signaled fence in a function so that
callers no longer needs t
From: John Harrison
The sync code has a facility for dumping current state information via
debugfs. It also has a way to re-use the same code for dumping to the
kernel log on an internal error. However, the redirection was rather
clunky and split the output across multiple prints at arbitrary
bou
From: John Harrison
The scheduler now supports sync framework fences being associated with
batch buffers. The execbuff IOCTL allows such fences to be passed in
from user land. This patch wires the two together so that the IOCTL no
longer needs to stall on the fence immediately. Instead the stall
From: Maarten Lankhorst
Debug output assumes all sync points are built on top of Android sync
points and when we start creating them from dma-fences will NULL ptr deref
unless taught about this.
v0.4: Corrected patch ownership.
v0.5: Removed redundant braces to keep style checker happy
Signed-
From: John Harrison
The sync framework is now used by the i915 driver. Therefore it can be
moved out of staging and into the regular tree. Also, the public
interfaces can actually be made public and exported.
v0.3: New patch for series.
Signed-off-by: John Harrison
Signed-off-by: Geoff Miller
From: John Harrison
There are useful statistics and debug information about fences that
can be returned via the scheduler's existing reporting mechanisms
(sysfs and debug output). These changes were previously part of the
patches that originally added those mechanisms. However, as the sync
framew
From: John Harrison
This patch set was originally part of the struct fence and scheduler
patch sets. However, it relies on de-staging the sync framework and
that is now being done by another group. Hence these patches had to be
split out into a separate series that can be merged after the de-stag
From: Maarten Lankhorst
This allows users of dma fences to create a android fence.
v0.2: Added kerneldoc. (Tvrtko Ursulin).
v0.4: Updated comments from review feedback by Maarten.
Signed-off-by: Maarten Lankhorst
Signed-off-by: Tvrtko Ursulin
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jes
On Wed, Jan 13, 2016 at 07:04:53PM +0200, Mika Kuoppala wrote:
> Hangcheck is run on irq context and might be active on a
s/irq/process/ that we pretend is irq-like.
> completely different CPU that is submitting requests. And as
> we have been very careful not to add locking to hangcheck to guard
On Wed, Jan 13, 2016 at 05:38:15PM +, Chris Wilson wrote:
> This is an expected error given the lack of the firmware so emit it at
> KERN_NOTICE and not KERN_ERROR. Also include the firmware URL in the
> user facing message so that the user can investigate and fix the issue
> on their own, and
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Arun Siluvery
> Sent: Wednesday, January 13, 2016 5:09 PM
> To: Gordon, David S ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Expose exec parameter to
This is an expected error given the lack of the firmware so emit it at
KERN_NOTICE and not KERN_ERROR. Also include the firmware URL in the
user facing message so that the user can investigate and fix the issue
on their own, and also explain the consequence in plain language.
The complete failure
From: Tomas Elf
Signed-off-by: Tomas Elf
---
Documentation/DocBook/gpu.tmpl | 476
drivers/gpu/drm/i915/i915_irq.c | 8 +-
2 files changed, 483 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
From: Tomas Elf
These new TDR-specific metrics have previously been added to
i915_hangcheck_info() in debugfs. During design review Chris Wilson asked for
these metrics to be added to the error state as well.
Signed-off-by: Tomas Elf
Cc: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i91
From: Tomas Elf
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows userland
applications to enable hang detection on individual batch buffers. The
detection mechanism itself is mostly bound to the hardware and the only thing
that the driver needs to do to support
From: Tomas Elf
Final enablement patch for GPU hang recovery using watchdog timeout.
Added execbuf flag for watchdog timeout in DRM kernel interface.
Signed-off-by: Tomas Elf
---
drivers/gpu/drm/i915/intel_lrc.c | 6 ++
include/uapi/drm/i915_drm.h | 5 -
2 files changed, 6 inserti
From: Tomas Elf
Added debugfs functions and embedded test infrastructure in the context event
interrupt handler for simulating the loss of context event interrupts so that a
context submission state inconsistency can be induced. This is useful for
testing the consistency checker pre-stage to the
From: Tomas Elf
1. The i915_wedged_set() function now allows for both legacy full GPU reset and
per-engine reset of one or more engines at a time:
a) Legacy hang recovery by passing 0.
b) Multiple engine hang recovery by passing in an engine flag mask
where bit 0 corr
From: Tomas Elf
Defined trace points and sprinkled the usage of these throughout the
TDR/watchdog implementation.
The following trace points are supported:
1. trace_i915_tdr_gpu_recovery:
Called at the onset of the full GPU reset recovery path.
2. trace_i915_tdr_engine_
From: Tomas Elf
Use is_locked parameter in __i915_wait_request() to determine if a thread
should be forced to back off and retry or if it can continue sleeping. Don't
return -EIO from __i915_wait_request since that is bad for the upper layers,
only -EAGAIN to signify reset in progress. (unless th
From: Tim Gore
Simulated hangs, as used by drv_hangman and some other IGT tests, are not
handled correctly with the new per-engine hang recovery mode. This patch fixes
several issues needed to get them working in the execlist case.
1) The "simulated" hang is effected by not submitting a particul
From: Tomas Elf
This is a partial port of the following patch from John Harrison's GPU
scheduler patch series: (patch sent to Intel-GFX with the subject line
"[Intel-gfx] [RFC 19/39] drm/i915: Added scheduler support to __wait_request()
calls" on Fri 17 July 2015)
Author: John Harrison
From: Tomas Elf
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows userland
applications to enable hang detection on individual batch buffers. The
detection mechanism itself is mostly bound to the hardware and the only thing
that the driver needs to do to support
From: Tomas Elf
This patch enables watchdog timeout hang detection as an entrypoint into the
driver error handler. This form of hang detection overrides the promotion logic
normally used by the periodic hang checker and instead allows for direct access
to the per-engine hang recovery path.
NOTE:
From: Tomas Elf
*** General ***
A recurring issue during long-duration operations testing of concurrent
rendering tasks with intermittent hangs is that context completion interrupts
following engine resets are sometimes lost. This becomes a real problem since
the hardware might have completed a p
From: Tomas Elf
This is the final enablement patch for per-engine hang recovery. It sets up
per-engine hang recovery to be used per default in favour of full GPU reset.
Legacy full GPU reset will no longer be the preferred mode of hang recovery and
will only be used as a fall-back in case of freq
From: Tomas Elf
i915_gem_wedge now returns a non-zero result in three different cases:
1. Legacy: A hang has been detected and full GPU reset is in progress.
2. Per-engine recovery:
a. A single engine reference can be passed to the function, in which
case only that engine will
From: Tomas Elf
There used to be a work queue separating the error handler from the hang
recovery path, which was removed a while back in this commit:
commit b8d24a06568368076ebd5a858a011699a97bfa42
Author: Mika Kuoppala
Date: Wed Jan 28 17:03:14 2015 +0200
These patches were sent previously a while ago[1] so rebased on latest nightly
and resending again for feedback.
This patch series adds support for Per engine resets, watchdog timeout
reset. Please see [1] for detailed description.
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/
From: Tomas Elf
With the per-engine hang recovery path already in place this patch adds
per-engine hang detection by letting the periodic hang checker detect hangs on
individual engines and communicate this to the error handler. During hang
checking every engine is checked and the hang detection
From: Tomas Elf
Makes i915_gem_reset_ring_status() public for use from engine reset path in
order to replicate the same behavior as in full GPU reset but for a single
engine.
Signed-off-by: Tomas Elf
Cc: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/d
From: Tomas Elf
TDR = Timeout Detection and Recovery.
This change introduces support for TDR-style per-engine reset as an initial,
less intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset recovery mode if necessary. Initially we're only
supporting gen8
From: Tomas Elf
GPU engine reset handshaking is something that is applicable to both full GPU
reset and engine reset, which is something that is part of the upcoming TDR
per-engine hang recovery patches. Break out the common engine reset
request/unrequest code (originally written by Mika Kuoppala
On Tue, Jan 12, 2016 at 09:08:30PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Here's a repost of some already reviewed patches from my larger fb
> offsets[] series [1] from last year, for the sake of the CI system.
>
> [1] http://lists.freedesktop.org/archives/intel-g
Hangcheck is run on irq context and might be active on a
completely different CPU that is submitting requests. And as
we have been very careful not to add locking to hangcheck to guard
against driver failures, we need to be careful with the coherency.
Update ring last seqno and add to request list
== Summary ==
Built on 0f3950521e4fd6b37f9d48d8484e2e0ce926ecca drm-intel-nightly:
2016y-01m-13d-15h-43m-52s UTC integration manifest
Test gem_basic:
Subgroup create-close:
dmesg-warn -> PASS (skl-i7k-2)
Test gem_cpu_reloc:
Subgroup basic:
dm
On Wed, Jan 13, 2016 at 05:14:15PM +0100, Daniel Vetter wrote:
> On Wed, Jan 13, 2016 at 05:13:31PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 13, 2016 at 02:33:47PM +, Chris Bainbridge wrote:
> > > The existing code assumes a sequential mapping of panel fitters to pipes
> > > (pfit0-pipeA, pf
It is beneficial to know the exact sw states of power wells
at the moment when unclaimed register access is detect.
When the backtrace has been printed to dmesg, it is
followed by a power well states, for example:
--[power wells, wakeref_count 2] --
Name sw statecount
display
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
re
On Wed, Jan 13, 2016 at 03:13:40PM -, Patchwork wrote:
> == Summary ==
>
> Built on 4d09810b01441f9124c072a866f608b748f92f6c drm-intel-nightly:
> 2016y-01m-13d-12h-32m-08s UTC integration manifest
>
> Test gem_ctx_basic:
> pass -> FAIL (hsw-gt2)
This seems to be
From: Tvrtko Ursulin
LRC code was calling GEM API like i915_gem_obj_ggtt_offset from
places where the struct_mutex cannot be grabbed (irq handlers).
To avoid that this patch caches some interesting bits and values
in the engine and context structures.
Some usages are also removed where they are
On Wed, Jan 13, 2016 at 05:13:31PM +0100, Daniel Vetter wrote:
> On Wed, Jan 13, 2016 at 02:33:47PM +, Chris Bainbridge wrote:
> > The existing code assumes a sequential mapping of panel fitters to pipes
> > (pfit0-pipeA, pfit1-pipeB, pfit2-pipeC), but boot firmware can
> > arbitrarily assign a
On Wed, Jan 13, 2016 at 02:33:47PM +, Chris Bainbridge wrote:
> The existing code assumes a sequential mapping of panel fitters to pipes
> (pfit0-pipeA, pfit1-pipeB, pfit2-pipeC), but boot firmware can
> arbitrarily assign any pipe to a pfit on IVB hardware e.g. Macbook UEFI
> uses pfit 0 and p
On 13/01/2016 14:11, Dave Gordon wrote:
On 13/01/16 12:53, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 11:44:39AM +0100, Artur Harasimiuk wrote:
Starting from Gen9 we can use IA-Coherent caches. Coherence may be not
required in certain cases and can be disabled in an easy way. To do this
we can
Am Montag, den 11.01.2016, 22:41 +0100 schrieb Daniel Vetter:
> So this one is special, since it tries to prevent races when userspace
> crashes simply by disabling the vblank machinery. Well except that imx
> always has vblanks enabled, and the disable_vblank hook actually just
> tries to cancel a
On Mon, 11 Jan 2016 22:41:06 +0100
Daniel Vetter wrote:
> The only thing this did was cancle pending flip events, and the core
> takes care of that now.
>
> Cc: Boris Brezillon
> Acked-by: Daniel Stone
> Reviewed-by: Alex Deucher
> Signed-off-by: Daniel Vetter
Acked-by: Boris Brezillon
>
The existing code assumes a sequential mapping of panel fitters to pipes
(pfit0-pipeA, pfit1-pipeB, pfit2-pipeC), but boot firmware can
arbitrarily assign any pipe to a pfit on IVB hardware e.g. Macbook UEFI
uses pfit 0 and pipe C for eDP1 when the firmware boots in a non-16:10
resolution (the last
This adds R8, RG88 and GR88, as well as the non-subsampled NV24/NV42 formats.
Signed-off-by: Emmanuel Gil Peyrot
---
include/drm/drm_fourcc.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index e741b09..59fc54d 100644
--- a/inclu
Some Gen7/8 production parts may have the Display Pipe C fused off.
In this case, the display hardware will prevent the Pipe C register bit
from being set to 1.
Fixed by adjusting pipe_count to reflect this.
v2: Rename HSW_PIPE_C_DISABLE to IVB_PIPE_C_DISABLE as it already exists
on ivybridge
On Wed, Jan 13, 2016 at 05:25:09PM +0200, Imre Deak wrote:
> On ke, 2016-01-13 at 14:53 +, Tvrtko Ursulin wrote:
> > On 13/01/16 14:41, Imre Deak wrote:
> > > On ke, 2016-01-13 at 14:32 +, Chris Wilson wrote:
> > > > On Wed, Jan 13, 2016 at 02:11:42PM +, Tvrtko Ursulin wrote:
> > > > >
On Wed, Jan 13, 2016 at 08:24:52AM -, Patchwork wrote:
> == Summary ==
>
> Built on 06d0112e293dfdea7f796d4085f755898850947b drm-intel-nightly:
> 2016y-01m-12d-21h-16m-40s UTC integration manifest
>
> Test gem_storedw_loop:
> Subgroup basic-render:
> pass -> DME
1 - 100 of 177 matches
Mail list logo
