Re: [Intel-gfx] [PATCH 3/6] drm/i915: Compact memcmp in i915_vma_compare()

On 11/01/2017 21:51, Chris Wilson wrote: In preparation for the next patch to convert to using an anonymous union and leaving the excess bytes in the union uninitialised, we first need to make sure we do not compare using those uninitialised bytes. We also want to preserve the compactness of

[Intel-gfx] [PATCH v2] drm/i915/bxt: Add MST support when do DPLL calculation

From: "Lee, Shawn C" Kernel oops was trigger by DP MST monitor/hub connected. DP MST series patch already upstream and MST should be support also. MST monitor will display normally with this change on bxt platform. Fixes: a277ca7dc01d ("drm/i915: Split

Re: [Intel-gfx] [PATCH v4] drm/i915/scheduler: emulate a scheduler for guc

On 11/01/2017 21:24, Chris Wilson wrote: This emulates execlists on top of the GuC in order to defer submission of requests to the hardware. This deferral allows time for high priority requests to gazump their way to the head of the queue, however it nerfs the GuC by converting it back into a

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: Add MST support when do DPLL calculation (rev2)

== Series Details == Series: drm/i915/bxt: Add MST support when do DPLL calculation (rev2) URL : https://patchwork.freedesktop.org/series/17815/ State : success == Summary == Series 17815v2 drm/i915/bxt: Add MST support when do DPLL calculation

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Pack the partial view size and offset into a single u64

On 11/01/2017 21:51, Chris Wilson wrote: Since the partial offset must be page aligned, we can use those low 12 bits to encode the size of the partial view (which then cannot be larger than 8MiB in pages). A requirement for avoiding unused bits inside the struct is imposed later by avoiding the

Re: [Intel-gfx] [PATCH v4] drm/i915/scheduler: emulate a scheduler for guc

On Thu, Jan 12, 2017 at 07:02:56AM +, Tvrtko Ursulin wrote: > > On 11/01/2017 21:24, Chris Wilson wrote: > >This emulates execlists on top of the GuC in order to defer submission of > >requests to the hardware. This deferral allows time for high priority > >requests to gazump their way to the

Re: [Intel-gfx] [PATCH 02/37] drm/i915: Provide a hook for selftests

On 11/01/2017 21:09, Chris Wilson wrote: Some pieces of code are independent of hardware but are very tricky to exercise through the normal userspace ABI or via debugfs hooks. Being able to create mock unit tests and execute them through CI is vital. Start by adding a central point where we can

[Intel-gfx] ✓ Fi.CI.BAT: success for Execlist based engine-reset (rev2)

== Series Details == Series: Execlist based engine-reset (rev2) URL : https://patchwork.freedesktop.org/series/16936/ State : success == Summary == Series 16936v2 Execlist based engine-reset https://patchwork.freedesktop.org/api/1.0/series/16936/revisions/2/mbox/ fi-bdw-5557u total:246

Re: [Intel-gfx] [PATCH 04/10] drm/i915/tdr: Modify error handler for per engine hang recovery

On Wed, Jan 11, 2017 at 08:18:11PM -0800, Michel Thierry wrote: > +/** > + * i915_reset - start either engine or full GPU reset to recover from a hang > + * @dev_priv: device private > + * > + * Wrapper function to initiate a GPU reset. If platform supports it, attempt > + * to reset the hung

Re: [Intel-gfx] [PATCH 02/37] drm/i915: Provide a hook for selftests

On Thu, Jan 12, 2017 at 07:29:59AM +, Tvrtko Ursulin wrote: > > On 11/01/2017 21:09, Chris Wilson wrote: > >diff --git a/tools/testing/selftests/drivers/gpu/i915.sh > >b/tools/testing/selftests/drivers/gpu/i915.sh > >index d407f0fa1e3a..c06d6e8a8dcc 100755 > >---

Re: [Intel-gfx] [PATCH] drm/i915: Detect vma reserved for execbuf in evict-for-node

On Thu, Jan 12, 2017 at 09:34:13AM +0200, Joonas Lahtinen wrote: > On ke, 2017-01-11 at 18:21 +, Chris Wilson wrote: > > The vma->exec_list is still the only means we have for both reserving an > > object in execbuf, and for constructing the eviction list. So during the > > construction of the

[Intel-gfx] [PATCH v4 00/10] Execlist based engine-reset (v4)

These patches are to add engine reset feature from Gen8. This is also referred to as Timeout detection and recovery (TDR). This complements to the full gpu reset feature available in i915 but it only allows to reset a particular engine instead of all engines thus providing a light weight engine

[Intel-gfx] [PATCH 07/10] drm/i915/tdr: Add engine reset count to error state

From: Arun Siluvery Driver maintains count of how many times a given engine is reset, useful to capture this in error state also. It gives an idea of how engine is coping up with the workloads it is executing before this error state. A follow-up patch will provide

[Intel-gfx] [PATCH 09/10] drm/i915/tdr: Enable Engine reset and recovery support

From: Arun Siluvery This feature is made available only from Gen8, for previous gen devices driver uses legacy full gpu reset. Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Tomas Elf

[Intel-gfx] [PATCH 05/10] drm/i915/tdr: Add support for per engine reset recovery

From: Arun Siluvery This change implements support for 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. This is only supported from Gen8 onwards.

[Intel-gfx] [PATCH 06/10] drm/i915: Skip reset request if there is one already

From: Mika Kuoppala To perform engine reset we first disable engine to capture its state. This is done by issuing a reset request. Because we are reusing existing infrastructure, again when we actually reset an engine, reset function checks engine mask and issues

Re: [Intel-gfx] [PATCH v4] drm/i915/scheduler: emulate a scheduler for guc

On Thu, Jan 12, 2017 at 07:14:54AM +, Chris Wilson wrote: > On Thu, Jan 12, 2017 at 07:02:56AM +, Tvrtko Ursulin wrote: > > > > On 11/01/2017 21:24, Chris Wilson wrote: > > >This emulates execlists on top of the GuC in order to defer submission of > > >requests to the hardware. This

[Intel-gfx] [PATCH 04/10] drm/i915/tdr: Modify error handler for per engine hang recovery

From: Arun Siluvery This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function

[Intel-gfx] [PATCH 01/10] drm/i915: Keep i915_handle_error kerneldoc parameters together

And before the function description. Tidy up from commit 14bb2c11796d70b ("drm/i915: Fix a buch of kerneldoc warnings"), all others kerneldoc blocks look ok. Cc: Tvrtko Ursulin Reviewed-by: Chris Wilson Reviewed-by: Tvrtko Ursulin

[Intel-gfx] [PATCH 03/10] drm/i915: Update i915.reset to handle engine resets

From: Arun Siluvery In preparation for engine reset work update this parameter to handle more than one type of reset. Default at the moment is still full gpu reset. Cc: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH 08/10] drm/i915/tdr: Export per-engine reset count info to debugfs

From: Arun Siluvery A new variable is added to export the reset counts to debugfs, this includes full gpu reset and engine reset count. This is useful for tests where they are expected to trigger reset; these counts are checked before and after the test to ensure

[Intel-gfx] [PATCH 02/10] drm/i915: Update i915_reset parameter for kerneldoc

Since commit c033666a94b57 ("drm/i915: Store a i915 backpointer from engine, and use it") i915_reset receives dev_priv, but the kerneldoc was not updated. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_drv.c | 2 +- 1 file changed, 1 insertion(+), 1

[Intel-gfx] [PATCH 10/10] drm/i915: Add engine reset count in get-reset-stats ioctl

Users/tests relying on the total reset count will start seeing a smaller number since most of the hangs can be handled by engine reset. Note that if reset engine x, context a running on engine y will be unaware and unaffected. To start the discussion, include just a total engine reset count. If

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Compact memcmp in i915_vma_compare()

On 12/01/2017 07:08, Tvrtko Ursulin wrote: On 11/01/2017 21:51, Chris Wilson wrote: In preparation for the next patch to convert to using an anonymous union and leaving the excess bytes in the union uninitialised, we first need to make sure we do not compare using those uninitialised bytes.

Re: [Intel-gfx] [PATCH] drm/i915: Detect vma reserved for execbuf in evict-for-node

On ke, 2017-01-11 at 18:21 +, Chris Wilson wrote: > The vma->exec_list is still the only means we have for both reserving an > object in execbuf, and for constructing the eviction list. So during the > construction of the eviction list, we must treat anything already on the > exec_list as

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

On 11/01/17 18:08, Chris Wilson wrote: > On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote: >> With kernel 4.10rc3 running as Xen dm0 I get at each boot: >> >> [ 49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell >> [1431], reason: Hang on render ring, action: reset >> [

Re: [Intel-gfx] [igvt-g-dev] [PATCH v2 2/3] drm/i915: Extract reserving space in the GTT to a helper

On 2017.01.11 11:23:11 +, Chris Wilson wrote: > Extract drm_mm_reserve_node + calling i915_gem_evict_for_node into its > own routine so that it can be shared rather than duplicated. > > v2: Kerneldoc > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH v4 00/10] Execlist based engine-reset (v4)

I'm sorry to do this, but there is a regression fix for gen3 required first that makes this more complicated. https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=prescheduler=de399a0a6baae97910796d81d8b9324db3fdd77c

[Intel-gfx] [PATCH 07/10] drm/i915/psr: set PSR_MASK bits for deep sleep

Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system to go to deep sleep while in psr2.PSR2_STATUS bit 31:28 should report value 8 , if system enters deep sleep state. Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set, flickering is observed on psr2 panel. v2: (Ilia Mirkin) - Remove

Re: [Intel-gfx] [PATCH] drm/i915/huc: Support HuC authentication

On Wed, Jan 11, 2017 at 05:36:49AM -0800, Anusha Srivatsa wrote: > From: Peter Antoine > > The HuC authentication is done by host2guc call. The HuC RSA keys > are sent to GuC for authentication. > > v2: rebased on top of drm-intel-nightly. > changed name format and

[Intel-gfx] [PATCH] drm/i915: Add a sanity check that no request is submitted in the middle

It is an error to start a new request on the same timeline (ringbuffer) as the current one before the current is submitted. If there are two requests emitting to the ringbuffer at the same time, the operation is undefined. We can catch this by checking for the timeline having a later seqno than

[Intel-gfx] [PATCH] drm/i915/huc: Add HuC fw loading support

The HuC loading process is similar to GuC. The intel_uc_fw_fetch() is used for both cases. HuC loading needs to be before GuC loading. The WOPCM setting must be done early before loading any of them. v2: rebased on-top of drm-intel-nightly. removed if(HAS_GUC()) before the guc call.

[Intel-gfx] [PATCH 04/10] drm/i915/psr: disable aux_frame_sync on psr2 exit

Screen freeze observed if AUX_FRAME_SYNC is not disabled on psr2 exit.AUX_FRAME_SYNC needed for psr2 is enabled during psr2 entry. It must be disabled on psr2 exit. v2: rebase Cc: Rodrigo Vivi Cc: Jim Bride Signed-off-by: Vathsala Nagaraju

[Intel-gfx] [PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2

As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15 must be programmed in psr2 enable sequence. bit 12 : Program Transcoder EDP VSC DIP header with a valid setting for PSR2 and Set CHICKEN_TRANS_EDP(0x420cc) bit 12 for programmable header packet. bit 15 : Set CHICKEN_TRANS_EDP(0x420cc) bit

Re: [Intel-gfx] [PATCH] drm/i915/guc: Make sure vma containing firmware is GuC mappable

On Wed, Jan 11, 2017 at 04:17:39PM +0100, Michał Winiarski wrote: > Since commit 4741da925fa3 ("drm/i915/guc: Assert that all GGTT offsets used > by the GuC are mappable"), we're asserting that GuC firmware is in the > GuC mappable range. > Except we're not pinning the object with bias, which

Re: [Intel-gfx] [PATCH v6] drm: add fourcc codes for 16bit R and RG

On 17-01-11 17:05:04, Ville Syrjälä wrote: On Thu, Jan 05, 2017 at 02:45:37PM +0100, Christian König wrote: Am 05.01.2017 um 12:37 schrieb Ville Syrjälä: > On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote: >> From: Rainer Hochecker >> >> This adds fourcc

Re: [Intel-gfx] [PATCH] drm/i915: Add a sanity check that no request is submitted in the middle

On ke, 2017-01-11 at 14:08 +, Chris Wilson wrote: > It is an error to start a new request on the same timeline (ringbuffer) > as the current one before the current is submitted. If there are two > requests emitting to the ringbuffer at the same time, the operation is > undefined. We can catch

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Invalidate the guc ggtt TLB upon insertion

On 11/01/2017 13:13, Chris Wilson wrote: Move the GuC invalidation of its ggtt TLB to where we perform the ggtt modification rather than proliferate it into all the callers of the insert (which may or may not in fact have to do the insertion). v2: Just do the guc invalidate unconditionally,

Re: [Intel-gfx] [PATCH] drm/i915: Add a sanity check that no request is submitted in the middle

Chris Wilson writes: > It is an error to start a new request on the same timeline (ringbuffer) > as the current one before the current is submitted. If there are two > requests emitting to the ringbuffer at the same time, the operation is > undefined. We can catch this

Re: [Intel-gfx] [PATCH] drm/i915: Add a sanity check that no request is submitted in the middle

On Wed, Jan 11, 2017 at 04:19:19PM +0200, Joonas Lahtinen wrote: > On ke, 2017-01-11 at 14:08 +, Chris Wilson wrote: > > It is an error to start a new request on the same timeline (ringbuffer) > > as the current one before the current is submitted. If there are two > > requests emitting to the

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

On 01/10/2017 11:43 PM, Daniel Vetter wrote: > On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote: >> On 01/10/2017 02:31 AM, Daniel Vetter wrote: >>> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e >>> Author: Daniel Vetter >>> Date: Sun Dec 18 14:35:45 2016

[Intel-gfx] ✓ Fi.CI.BAT: success for HuC Loading Patches (rev2)

== Series Details == Series: HuC Loading Patches (rev2) URL : https://patchwork.freedesktop.org/series/17499/ State : success == Summary == Series 17499v2 HuC Loading Patches https://patchwork.freedesktop.org/api/1.0/series/17499/revisions/2/mbox/ fi-bdw-5557u total:246 pass:232

Re: [Intel-gfx] [PATCH] drm/i915/huc: Add HuC fw loading support

On Wed, Jan 11, 2017 at 05:15:14AM -0800, Anusha Srivatsa wrote: > The HuC loading process is similar to GuC. The intel_uc_fw_fetch() > is used for both cases. > > HuC loading needs to be before GuC loading. The WOPCM setting must > be done early before loading any of them. > > v2: rebased

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Invalidate the guc ggtt TLB upon insertion

== Series Details == Series: series starting with [1/3] drm/i915: Invalidate the guc ggtt TLB upon insertion URL : https://patchwork.freedesktop.org/series/17829/ State : failure == Summary == Series 17829v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915/huc: Add HuC fw loading support

On Wed, Jan 11, 2017 at 03:13:29PM +0100, Michal Wajdeczko wrote: > > + vma = i915_gem_object_ggtt_pin(huc_fw->obj, NULL, 0, 0, 0); > > + if (IS_ERR(vma)) { > > + DRM_DEBUG_DRIVER("pin failed %d\n", (int)PTR_ERR(vma)); > > + return PTR_ERR(vma); > > + } Just asking a

Re: [Intel-gfx] [PATCH v6] drm: add fourcc codes for 16bit R and RG

On Thu, Jan 05, 2017 at 02:45:37PM +0100, Christian König wrote: > Am 05.01.2017 um 12:37 schrieb Ville Syrjälä: > > On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote: > >> From: Rainer Hochecker > >> > >> This adds fourcc codes for 16bit planes required for

Re: [Intel-gfx] [PATCH] drm/i915: Suppress switch_mm emission between the same aliasing_ppgtt

On 11/01/17 14:58, Joonas Lahtinen wrote: On ke, 2017-01-11 at 12:14 +, Chris Wilson wrote: When switching between contexts using the aliasing_ppgtt, the VM is shared. We don't need to reload the PD registers unless they are dirty. Martin Peres reported an issue that looks like corruption

Re: [Intel-gfx] DP compliance failure due to dithering for 18bpp video pattern

On Wed, Jan 11, 2017 at 05:09:16PM +0200, Jani Nikula wrote: > On Tue, 10 Jan 2017, Manasi Navare wrote: > > Hi All, > > > > We are seeing CRC check failures in some of the 18bpp video pattern > > DP Compliance tests causing the tests to fail. On further investigation,

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

On Wed, Jan 11, 2017 at 07:24:45AM -0800, Dave Hansen wrote: > On 01/10/2017 11:43 PM, Daniel Vetter wrote: > > On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote: > >> On 01/10/2017 02:31 AM, Daniel Vetter wrote: > >>> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e > >>> Author: Daniel

Re: [Intel-gfx] DP compliance failure due to dithering for 18bpp video pattern

On Tue, 10 Jan 2017, Manasi Navare wrote: > Hi All, > > We are seeing CRC check failures in some of the 18bpp video pattern > DP Compliance tests causing the tests to fail. On further investigation, it is > rootcaused to dithering that the i915 driver enables in case of

[Intel-gfx] [PATCH] drm/i915/guc: Make sure vma containing firmware is GuC mappable

Since commit 4741da925fa3 ("drm/i915/guc: Assert that all GGTT offsets used by the GuC are mappable"), we're asserting that GuC firmware is in the GuC mappable range. Except we're not pinning the object with bias, which means it's possible to trigger this assert. Let's add a proper bias. Cc:

[Intel-gfx] [PATCH v3] drm/i915/scheduler: emulate a scheduler for guc

This emulates execlists on top of the GuC in order to defer submission of requests to the hardware. This deferral allows time for high priority requests to gazump their way to the head of the queue, however it nerfs the GuC by converting it back into a simple execlist (where the CPU has to wake up

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

On Wed, Jan 11, 2017 at 4:24 PM, Dave Hansen wrote: > On 01/10/2017 11:43 PM, Daniel Vetter wrote: >> On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote: >>> On 01/10/2017 02:31 AM, Daniel Vetter wrote: commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Suppress switch_mm emission between the same aliasing_ppgtt

On Wed, Jan 11, 2017 at 01:01:18PM +, Chris Wilson wrote: > On Wed, Jan 11, 2017 at 12:56:03PM -, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Suppress switch_mm emission between the same > > aliasing_ppgtt > > URL :

[Intel-gfx] [PATCH] drm/i915/huc: Support HuC authentication

From: Peter Antoine The HuC authentication is done by host2guc call. The HuC RSA keys are sent to GuC for authentication. v2: rebased on top of drm-intel-nightly. changed name format and upped version 1.7. v3: rebased on top of drm-intel-nightly. v4: changed

Re: [Intel-gfx] [PATCH i-g-t v3] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation

Hi The copyright statements still need the year corrected. intel_dp_compliance needs to be added to tools/.gitignore Some new comments also: - Why do some of the prints have \r\n? - Building intel_dp_compliance should actually be made conditional upon HAVE_UDEV -- Petri Latvala On Fri,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: Improve RGB limited range handling a bit

== Series Details == Series: drm/edid: Improve RGB limited range handling a bit URL : https://patchwork.freedesktop.org/series/17825/ State : success == Summary == Series 17825v1 drm/edid: Improve RGB limited range handling a bit

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Add render decompression support

On Tue, Jan 10, 2017 at 9:04 AM, Ville Syrjälä < ville.syrj...@linux.intel.com> wrote: > On Mon, Jan 09, 2017 at 11:20:57AM -0800, Jason Ekstrand wrote: > > On Thu, Jan 5, 2017 at 7:14 AM, wrote: > > > > > From: Ville Syrjälä > > > >

[Intel-gfx] Anonymous ggtt_view params

It makes reading the vma->ggtt_view code more pleasant, but at an unfortunate cost in header complexity to ensure that no unwanted bits are in the struct and that gcc doesn't double the size of a few inlined functions. I like it, but I am biased. -Chris

[Intel-gfx] [PATCH 3/6] drm/i915: Compact memcmp in i915_vma_compare()

In preparation for the next patch to convert to using an anonymous union and leaving the excess bytes in the union uninitialised, we first need to make sure we do not compare using those uninitialised bytes. We also want to preserve the compactness of the code, avoiding a second call to memcmp or

[Intel-gfx] [PATCH 1/6] drm/i915: Name the anonymous structs inside i915_ggtt_view

Naming this pair will become useful shortly... Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_gtt.h | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git

[Intel-gfx] [PATCH 4/6] drm/i915: Convert i915_ggtt_view to use an anonymous union

Save a lot of characters by making the union anonymous, with the side-effect of ignoring unset bits when comparing views. v2: Roll up the memcmps back into one. v3: And split again as Ville points out we can't trust the compiler. Signed-off-by: Chris Wilson Cc: Daniel

[Intel-gfx] [PATCH 5/6] drm/i915: Eliminate superfluous i915_ggtt_view_rotated

It is only being used to clear a struct and set the type, after which it is overwritten. Since we no longer check the unset bits of the union, skipping the clear is permissible. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH 6/6] drm/i915: Eliminate superfluous i915_ggtt_view_normal

Since commit 058d88c4330f ("drm/i915: Track pinned VMA"), there is only one user of i915_ggtt_view_normal rodate. Just treat NULL as no special view in pin_to_display() like everywhere else. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH 2/6] drm/i915: Pack the partial view size and offset into a single u64

Since the partial offset must be page aligned, we can use those low 12 bits to encode the size of the partial view (which then cannot be larger than 8MiB in pages). A requirement for avoiding unused bits inside the struct is imposed later by avoiding the clear of the struct (or of copying around

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Detect vma reserved for execbuf in evict-for-node

== Series Details == Series: drm/i915: Detect vma reserved for execbuf in evict-for-node URL : https://patchwork.freedesktop.org/series/17846/ State : success == Summary == Series 17846v1 drm/i915: Detect vma reserved for execbuf in evict-for-node

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Invalidate the guc ggtt TLB upon insertion (rev2)

== Series Details == Series: series starting with [1/3] drm/i915: Invalidate the guc ggtt TLB upon insertion (rev2) URL : https://patchwork.freedesktop.org/series/17829/ State : failure == Summary == Series 17829v2 Series without cover letter

[Intel-gfx] [PATCH 09/37] drm/i915: Mock infrastructure for request emission

Create a fake engine that runs requests using a timer to simulate hw. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c| 4 + drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 11 +- drivers/gpu/drm/i915/selftests/mock_context.c

[Intel-gfx] [PATCH 10/37] drm/i915: Create a fake object for testing huge allocations

We would like to be able to exercise huge allocations even on memory constrained devices. To do this we create an object that allocates only a few pages and remaps them across its whole range - each page is reused multiple times. We can therefore pretend we are rendering into a much larger object.

[Intel-gfx] [PATCH 03/37] drm/i915: Add some selftests for sg_table manipulation

Start exercising the scattergather lists, especially looking at iteration after coalescing. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem.c| 11 +-

[Intel-gfx] [PATCH 01/37] drm: Provide a driver hook for drm_dev_release()

Some state is coupled into the device lifetime outside of the load/unload timeframe and requires teardown during final unreference from drm_dev_release(). For example, dmabufs hold both a device and module reference and may live longer than expected (i.e. the current pattern of the driver tearing

[Intel-gfx] [PATCH 05/37] drm/i915: Add unit tests for the breadcrumb rbtree, completion

Second retroactive test, make sure that the waiters are removed from the global wait-tree when their seqno completes. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c | 107

[Intel-gfx] [PATCH 04/37] drm/i915: Add unit tests for the breadcrumb rbtree, insert/remove

First retroactive test, make sure that the waiters are in global seqno order after random inserts and removals. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/Makefile | 1 +

[Intel-gfx] [PATCH 02/37] drm/i915: Provide a hook for selftests

Some pieces of code are independent of hardware but are very tricky to exercise through the normal userspace ABI or via debugfs hooks. Being able to create mock unit tests and execute them through CI is vital. Start by adding a central point where we can execute unit tests and a parameter to

[Intel-gfx] Selftests

A small smattering of selftests. Coverage is getting better, but still a long way from providing coverage of every path I have planned. :| The tests we do have do nicely demonstrated the ease at which some in-depth testing can be done in the kernel, some that would be impossible from userspace.

[Intel-gfx] [PATCH 35/37] drm/i915: Live testing for context execution

Check we can create and execution within a context. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c| 1 + drivers/gpu/drm/i915/selftests/i915_gem_context.c | 302 +

[Intel-gfx] [PATCH 33/37] drm/i915: Verify page layout for rotated VMA

Exercise creating rotated VMA and checking the page order within. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/i915_vma.c | 130 ++ 1 file changed, 130 insertions(+) diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c

[Intel-gfx] [PATCH 30/37] drm/i915: Exercise filling and removing random ranges from the live GTT

Test the low-level i915_address_space interfaces to sanity check the live insertion/removal of address ranges. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 140 ++ 1 file changed, 140 insertions(+) diff --git

[Intel-gfx] [PATCH 23/37] drm/i915: Add some mock tests for dmabuf interop

Check that we can create both dmabuf and objects from dmabuf. v2: Cleanups, correct include, fix unpin on dead path and prevent explosion on dmabuf init failure Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ---

[Intel-gfx] [PATCH 27/37] drm/i915: Exercising filling the top/bottom portions of the ppgtt

Allocate objects with varying number of pages (which should hopefully consist of a mixture of contiguous page chunks and so coalesced sg lists) and check that the sg walkers in insert_pages cope. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 32/37] drm/i915: Exercise i915_vma_pin/i915_vma_insert

High-level testing of the struct drm_mm by verifying our handling of weird requests to i915_vma_pin. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_vma.c | 4 +- drivers/gpu/drm/i915/i915_vma.h | 4 +-

[Intel-gfx] [PATCH 18/37] drm/i915: Test exhaustion of the mmap space

An unlikely error condition that we can simulate by stealing the most of the range before trying to insert new objects. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/i915_gem_object.c | 137 +++ 1 file changed, 137 insertions(+)

[Intel-gfx] [PATCH 29/37] drm/i915: Fill different pages of the GTT

Exercise filling different pages of the GTT Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 130 ++ 1 file changed, 130 insertions(+) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c

[Intel-gfx] [PATCH 28/37] drm/i915: Exercising filling the top/bottom portions of the global GTT

Same test as previously for the per-process GTT instead applied to the global GTT. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 118 +++--- 1 file changed, 88 insertions(+), 30 deletions(-) diff --git

[Intel-gfx] [PATCH 22/37] drm/i915: Sanity check all registers for matching fw domains

Add a late selftest that walks over all forcewake registers (those below 0x4) and uses the mmio debug register to check to see if any are unclaimed. This is possible if we fail to wake the appropriate powerwells for the register. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 34/37] drm/i915: Test creation of partial VMA

Mock testing to ensure we can create and lookup partial VMA. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/i915_vma.c | 179 ++ 1 file changed, 179 insertions(+) diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c

[Intel-gfx] [PATCH 31/37] drm/i915: Test creation of VMA

Simple test to exercise creation and lookup of VMA within an object. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_vma.c| 3 + .../gpu/drm/i915/selftests/i915_mock_selftests.h | 1 + drivers/gpu/drm/i915/selftests/i915_vma.c

[Intel-gfx] [PATCH 21/37] drm/i915: Test all fw tables during mock selftests

In addition to just testing the fw table we load, during the initial mock testing we can test that all tables are valid (so the testing is not limited to just the platforms that load that particular table). Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH 19/37] drm/i915: Test coherency of and barriers between cache domains

Write into an object using WB, WC, GTT, and GPU paths and make sure that our internal API is sufficient to ensure coherent reads and writes. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c| 1 +

[Intel-gfx] [PATCH 37/37] drm/i915: Add initial selftests for hang detection and resets

Check that we can reset the GPU and continue executing from the next request. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_hangcheck.c | 4 + .../gpu/drm/i915/selftests/i915_live_selftests.h | 1 +

[Intel-gfx] [PATCH v4] drm/i915/scheduler: emulate a scheduler for guc

This emulates execlists on top of the GuC in order to defer submission of requests to the hardware. This deferral allows time for high priority requests to gazump their way to the head of the queue, however it nerfs the GuC by converting it back into a simple execlist (where the CPU has to wake up

Re: [Intel-gfx] [PATCH 4/4] drm: Resurrect atomic rmfb code, v2

On Thu, Dec 15, 2016 at 03:29:45PM +0100, Maarten Lankhorst wrote: > From: Daniel Vetter > > This was somehow lost between v3 and the merged version in Maarten's > patch merged as: > > commit f2d580b9a8149735cbc4b59c4a8df60173658140 > Author: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Disable all crtcs during driver unload.

On Thu, Dec 15, 2016 at 03:29:44PM +0100, Maarten Lankhorst wrote: > We may keep the crtc's enabled when userspace unsets all framebuffers but > keeps the crtc active. This exposes a WARN in fbc_global disable, and > a lot of bugs in our hardware readout code. Solve this by disabling > all crtc's

[Intel-gfx] [PATCH v2 2/5] drm/edid: Introduce drm_default_rgb_quant_range()

From: Ville Syrjälä Make the code selecting the RGB quantization range a little less magicy by wrapping it up in a small helper. v2: s/adjusted_mode/mode in vc4 to make it actually compile Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled, psr1 should be disabled.When psr2 is exited , bit 31 of reg PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL (psr1 control register)is set to 0. Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register) instead of

Re: [Intel-gfx] [PATCH] drm/i915: Suppress switch_mm emission between the same aliasing_ppgtt

On Wed, Jan 11, 2017 at 05:35:08PM +0200, Martin Peres wrote: > On 11/01/17 14:58, Joonas Lahtinen wrote: > >On ke, 2017-01-11 at 12:14 +, Chris Wilson wrote: > >>When switching between contexts using the aliasing_ppgtt, the VM is > >>shared. We don't need to reload the PD registers unless

[Intel-gfx] [drm-intel:for-linux-next 1/4] htmldocs: drivers/gpu/drm/i915/i915_gem_gtt.c:3594: warning: No description found for parameter 'vm'

tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: c781c978e784c50dcd7cb312fe17f5281923f55b commit: e007b19d7ba7424735fd4f17a355b145ae153e4c [1/4] drm/i915: Use the MRU stack search after evicting reproduce: make htmldocs All warnings (new ones prefixed by >>): make[3]:

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix POWER_DOMAIN_AUDIO refcounting.

On Thu, Dec 15, 2016 at 03:29:43PM +0100, Maarten Lankhorst wrote: > If the crtc was brought up with audio before the driver loads, > then crtc_disable will remove a refcount to audio that doesn't exist > before. > > Fortunately we already set power domains on readout, so we can just add > the

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

On 01/11/2017 07:39 AM, Daniel Vetter wrote: > Hm, just cherry-picked it on top of Linus' latest 4.10 git, applies > cleanly there. The substituation was for 4.9. I can send you the patch > here, but seems all fine from what I can tell ... All of the printk's that I added were making it fail to

Re: [Intel-gfx] [PATCH 2/5] drm/edid: Introduce drm_default_rgb_quant_range()

On Wed, Jan 11, 2017 at 02:57:22PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Make the code selecting the RGB quantization range a little less magicy > by wrapping it up in a small helper. > > Signed-off-by: Ville Syrjälä

  1   2   3   >