[Intel-gfx] [PATCH v6] drm/i915/guc: capture GuC logs if FW fails to load

We're currently deleting the GuC logs if the FW fails to load, but those are still useful to understand why the loading failed. Keeping the object around allows us to access them after driver load is completed. v2: keep the object around instead of using kernel memory (chris) don't store the

Re: [Intel-gfx] [PATCH 06/14] drm/i915/perf: rework mux configurations queries

On 22/05/17 17:51, Matthew Auld wrote: On 05/17, Lionel Landwerlin wrote: Gen8+ might have mux configurations per slices/subslices. Depending on whether slices/subslices have been fused off, only part of the configuration needs to be applied. This change reworks the mux configurations query

[Intel-gfx] [PATCH v8 06/20] drm/i915: Export per-engine reset count info to debugfs

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 the same. v2: Include reset engine count in

[Intel-gfx] [PATCH v8 03/20] drm/i915: Modify error handler for per engine hang recovery

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 where applicable (which fails at this point because

[Intel-gfx] [PATCH v8 04/20] drm/i915: Add support for per engine reset recovery

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. Hangchecker determines which engines are hung and invokes

[Intel-gfx] [PATCH v8 08/20] drm/i915: Enable Engine reset and recovery support

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 Signed-off-by: Arun Siluvery

[Intel-gfx] [PATCH v8 10/20] drm/i915/selftests: reset engine self tests

Check that we can reset specific engines, also check the fallback to full reset if something didn't work. v2: rebase. v3: use RESET_ENGINE_IN_PROGRESS flag. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 149

[Intel-gfx] [PATCH v8 11/20] drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder

From: Daniele Ceraolo Spurio The mmio_start offset for the whitelist is the first FORCE_TO_NONPRIV register the GuC can use to restore the provided whitelist when an engine reset via GuC (which we still don't support) is triggered. We're currently adding the

[Intel-gfx] [PATCH v8 16/20] drm/i915: Watchdog timeout: IRQ handler for gen8+

*** 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 this form of

[Intel-gfx] [PATCH v8 07/20] drm/i915: Carry on with reset even if hw engine is not ready

We try to get the engines ready/idle before triggering the reset, but it has been seen that sometimes the hw never acknowledges this. If we miss the acknowledgment, carry on with the reset instead of leaving the GPU in a wedged state. The frequency of missed acknowledgment from hw is low, but it

[Intel-gfx] [PATCH v8 02/20] drm/i915: Update i915.reset to handle engine resets

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 Signed-off-by: Arun Siluvery

[Intel-gfx] [PATCH v8 00/20] Gen8+ engine-reset

These patches add the reset-engine 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 reset

[Intel-gfx] [PATCH v8 01/20] drm/i915: Look for active requests earlier in the reset path

And store the active request so that we only search for it once. v2: Check for request completion inside _prepare_engine, don't use ECANCELED, remove unnecessary null checks (Chris). v3: Capture active requests during reset_prepare and store it the engine hangcheck obj. v4: Rename commit,

[Intel-gfx] [PATCH v8 20/20] drm/i915: Watchdog timeout: Export media reset count from GuC to debugfs

From firmware v8.8, GuC provides the count of media engine resets (watchdog timeout). This information is available in the GuC shared context data struct, which resides in the first page of the default (kernel) lrc context. Since GuC handled engine resets are transparent for kernel and user,

[Intel-gfx] [PATCH v8 19/20] drm/i915: Watchdog timeout: Include threshold value in error state

Save the watchdog threshold (in us) as part of the engine state. v2: Only do it for gen8+ (and prevent a missing-case warn). Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gpu_error.c | 12 2

[Intel-gfx] [PATCH v8 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

Final enablement patch for GPU hang detection using watchdog timeout. Using the gem_context_setparam ioctl, users can specify the desired timeout value in microseconds, and the driver will do the conversion to 'timestamps'. The recommended default watchdog threshold for video engines is 6 us,

[Intel-gfx] [PATCH v8 14/20] drm/i915/guc: Add support for reset engine using GuC commands

This patch adds per engine reset and recovery (TDR) support when GuC is used to submit workloads to GPU. In the case of i915 directly submission to ELSP, driver manages hang detection, recovery and resubmission. With GuC submission these tasks are shared between driver and GuC. i915 is still

Re: [Intel-gfx] [PATCH] drm: Fix deadlock retry loop in page_flip_ioctl

2017-05-22 16:59 GMT+03:00 Daniel Vetter : > I failed to properly onion-wrap the unwind code: We acquire the vblank > reference before we start with the wait-wound locking dance, hence we > must make sure we retry before we drop the reference. Oops. > > v2: The vblank_put

Re: [Intel-gfx] [PATCH 14/14] drm/i915/perf: add GLK support

On 05/17, Lionel Landwerlin wrote: > Signed-off-by: Lionel Landwerlin Hmm, are we not missing the GEN9_OA_DEBUG_DISABLE_CLK_RATIO_REPORTS part, so disabling slice/unslice clock ratio change reports, like we do on all other gen9 platforms? For the timestamp base

Re: [Intel-gfx] [PATCH v5] dma-buf/sync-file: Defer creation of sync_file->name

On Tue, May 16, 2017 at 12:10:42PM +0100, Chris Wilson wrote: > Constructing the name takes the majority of the time for allocating a > sync_file to wrap a fence, and the name is very rarely used (only via > the sync_file status user interface). To reduce the impact on the common > path (that of

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/guc: capture GuC logs if FW fails to load (rev6)

On 22/05/17 11:21, Patchwork wrote: == Series Details == Series: drm/i915/guc: capture GuC logs if FW fails to load (rev6) URL : https://patchwork.freedesktop.org/series/23982/ State : warning == Summary == Series 23982v6 drm/i915/guc: capture GuC logs if FW fails to load

[Intel-gfx] [PATCH v8 15/20] drm/i915: Watchdog timeout: Pass GuC shared data structure during param load

For watchdog / media reset, the firmware must know the address of the shared data page (the first page of the default context). This information should be in DWORD 9 of the GUC_CTL structure. v2: Use guc_ggtt_offset (Chris). Store the ggtt offset of the default ctx as we needed for

[Intel-gfx] [PATCH v8 05/20] drm/i915: Add engine reset count to error state

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 this information in debugfs. v2:

[Intel-gfx] [PATCH v8 12/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

GuC expects a list of registers from the driver which are saved/restored during engine reset. The type of value to be saved is controlled by flags. We provide a minimal set of registers that we want GuC to save and restore. This is not an issue in case of engine reset as driver initializes most of

[Intel-gfx] [PATCH v8 09/20] 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

[Intel-gfx] [PATCH v8 13/20] drm/i915/guc: Rename the function that resets the GuC

intel_guc_reset sounds more like the microcontroller is the one performing a reset, while in this case is the opposite. intel_reset_guc not only makes it clearer, it follows the other intel_reset functions available. v2: Print error message in English. Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH v8 17/20] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+

Emit the required commands into the ring buffer for starting and stopping the watchdog timer before/after batch buffer start during batch buffer submission. v2: Support watchdog threshold per context engine, merge lri commands, and move watchdog commands emission to emit_bb_start. Request space

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Serialize GTT Updates on BXT

== Series Details == Series: drm/i915: Serialize GTT Updates on BXT URL : https://patchwork.freedesktop.org/series/24793/ State : success == Summary == Series 24793v1 drm/i915: Serialize GTT Updates on BXT https://patchwork.freedesktop.org/api/1.0/series/24793/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

On Thu, 2017-05-04 at 12:21 +0300, Andy Shevchenko wrote: > acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 > bytes. Instead we convert them to use uuid_le type. At the same time > we > convert current users. > > acpi_str_to_uuid() becomes useless after the conversion and

Re: [Intel-gfx] [PATCH v6] drm/i915/guc: capture GuC logs if FW fails to load

On Mon, May 22, 2017 at 10:50:28AM -0700, Daniele Ceraolo Spurio wrote: > We're currently deleting the GuC logs if the FW fails to load, but those > are still useful to understand why the loading failed. Keeping the > object around allows us to access them after driver load is completed. > > v2:

Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT

On Mon, May 22, 2017 at 11:07:25AM -0700, Jon Bloomfield wrote: > BXT requires accesses to the GTT (i.e. PTE updates) to be serialized > when IOMMU is enabled. Serialised with what, since all writes are serialized already? The reason is that you need to explain the hw model you are protecting,

[Intel-gfx] [PATCH v3 3/8] drm/i915/guc: Submit GuC workitems containing coalesced requests

To create an upper bound on number of GuC workitems, we need to change the way that requests are being submitted. Rather than submitting each request as an individual workitem, we can do coalescing in a similar way we're handlig execlist submission ports. We also need to stop pretending that we're

[Intel-gfx] [PATCH 2/8] drm/i915/guc: Skip port assign on first iteration of GuC dequeue

If port[0] is occupied and we're trying to dequeue request from different context, we will inevitably hit BUG_ON in port_assign. Let's skip it - similar to what we're doing in execlists counterpart. Fixes: 77f0d0e925e8a0 ("drm/i915/execlists: Pack the count into the low bits of the

[Intel-gfx] [PATCH v2 1/8] drm/i915: Remove misleading comment in request_alloc

Passing NULL ctx to request_alloc would lead to null-ptr-deref. v2: Let's not replace the comment with a BUG_ON Signed-off-by: Michał Winiarski --- drivers/gpu/drm/i915/i915_gem_request.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[Intel-gfx] ✓ Fi.CI.BAT: success for Gen8+ engine-reset (rev11)

== Series Details == Series: Gen8+ engine-reset (rev11) URL : https://patchwork.freedesktop.org/series/21868/ State : success == Summary == Series 21868v11 Gen8+ engine-reset https://patchwork.freedesktop.org/api/1.0/series/21868/revisions/11/mbox/ Test kms_flip: Subgroup

[Intel-gfx] [PATCH v2 6/8] drm/i915/scheduler: Split insert_request

We'd like to reuse the priolist lookup in request resubmission path, let's split insert_request to make that happen. v2: Handle allocation error in lookup rather than in caller (Chris) Cc: Chris Wilson Cc: Jeff McGee Cc: Joonas Lahtinen

[Intel-gfx] [PATCH v3 7/8] drm/i915/scheduler: Use priorities when resubmitting after reset

Now that we're able to unsubmit requests, we can take advantage of it during reset. Rather than resubmitting the previous workload directly to GuC/ELSP, we can simply move the requests back to priority queue, submitting from the tasklet instead. v2: Move the tasklet schedule out for legacy

[Intel-gfx] [PATCH 8/8] HAX: Enable GuC submission for CI

--- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index b6a7e36..9dcc8a0 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Submit GuC workitems containing coalesced requests

On Fri, May 19, 2017 at 11:08:05AM -0700, Daniele Ceraolo Spurio wrote: > > > On 19/05/17 06:23, Michał Winiarski wrote: > > To create an upper bound on number of GuC workitems, we need to change > > the way that requests are being submitted. Rather than submitting each > > request as an

[Intel-gfx] [PATCH v3 4/8] drm/i915/guc: Remove GuC wq reservation

Now that we have an upper bound on the number of work items being sent to GuC, we can remove the reservation. v2: Multiply by number of engines in compile time assert (Daniele) v3: Comment on reasoning behind the compile time assert (Chris) Cc: Chris Wilson Cc: Daniele

[Intel-gfx] [PATCH v2 5/8] drm/i915/scheduler: Remember request priority throughout its lifetime

Since request can be unsubmitted, we need to avoid overriding its priority during submission. Otherwise we won't be able to resubmit it with correct priority. v2: Limit DFS by excluding completed requests (Chris) Cc: Chris Wilson Cc: Jeff McGee

Re: [Intel-gfx] [PATCH 03/24] drm/i915: Store i915_gem_object_is_coherent() as a bit next to cache-dirty

Chris, I tested this together with your v3 (Mark cache dirty...) patch and verified tests are all passing. Tested-by : Dongwon Kim On Thu, May 18, 2017 at 10:46:17AM +0100, Chris Wilson wrote: > For ease of use (i.e. avoiding a few checks and function calls), store >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/8] drm/i915: Remove misleading comment in request_alloc

== Series Details == Series: series starting with [v2,1/8] drm/i915: Remove misleading comment in request_alloc URL : https://patchwork.freedesktop.org/series/24801/ State : failure == Summary == Series 24801v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Monday, May 22, 2017 1:05 PM > To: Bloomfield, Jon > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT > > On Mon, May

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable decoupled mmio for GEN9LP (rev3)

== Series Details == Series: drm/i915: Disable decoupled mmio for GEN9LP (rev3) URL : https://patchwork.freedesktop.org/series/24470/ State : success == Summary == Series 24470v3 drm/i915: Disable decoupled mmio for GEN9LP

[Intel-gfx] [PATCH] drm/i915: Disable GEN9LP decoupled mmio

From: Kai Chen This change is used as a backport fix from top of drm-intel ([PATCH] drm/i915: Disable decoupled mmio for GEN9LP) to disable decoupled mmio on GEN9LP for those shipped kernels as a quick fix. --- drivers/gpu/drm/i915/i915_pci.c | 1 - 1 file changed, 1

Re: [Intel-gfx] [PATCH v3 3/8] drm/i915/guc: Submit GuC workitems containing coalesced requests

On 22/05/17 15:07, Michał Winiarski wrote: To create an upper bound on number of GuC workitems, we need to change the way that requests are being submitted. Rather than submitting each request as an individual workitem, we can do coalescing in a similar way we're handlig execlist submission

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable GEN9LP decoupled mmio

== Series Details == Series: drm/i915: Disable GEN9LP decoupled mmio URL : https://patchwork.freedesktop.org/series/24803/ State : success == Summary == Series 24803v1 drm/i915: Disable GEN9LP decoupled mmio https://patchwork.freedesktop.org/api/1.0/series/24803/revisions/1/mbox/ Test

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Disable decoupled mmio for GEN9LP (rev4)

== Series Details == Series: drm/i915: Disable decoupled mmio for GEN9LP (rev4) URL : https://patchwork.freedesktop.org/series/24470/ State : failure == Summary == Series 24470v4 drm/i915: Disable decoupled mmio for GEN9LP

Re: [Intel-gfx] [PATCH] drm: Fix deadlock retry loop in page_flip_ioctl

On 22/05/17 10:59 PM, Daniel Vetter wrote: > I failed to properly onion-wrap the unwind code: We acquire the vblank > reference before we start with the wait-wound locking dance, hence we > must make sure we retry before we drop the reference. Oops. > > v2: The vblank_put must be after the

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: dma-buf support for GVT-g (rev4)

== Series Details == Series: drm/i915/gvt: dma-buf support for GVT-g (rev4) URL : https://patchwork.freedesktop.org/series/23686/ State : failure == Summary == Series 23686v4 drm/i915/gvt: dma-buf support for GVT-g https://patchwork.freedesktop.org/api/1.0/series/23686/revisions/4/mbox/ Test

[Intel-gfx] [PATCH] drm/i915: Disable decoupled mmio for GEN9LP

From: Kai Chen The decoupled mmio feature doesn't work as intended by HW team. Enabling it with forcewake will only make debugging efforts more difficult, so let's just simply remove it. v2: - Remove dead code related to GEN9LP decoupled mmio. - Change backgrounds: In

Re: [Intel-gfx] [PATCH 12/14] drm/i915: add KBL GT2/GT3 check macros

On 05/17, Lionel Landwerlin wrote: > Signed-off-by: Lionel Landwerlin With a proper commit message: Reviewed-by: Matthew Auld > --- > drivers/gpu/drm/i915/i915_drv.h | 4 > 1 file changed, 4 insertions(+) > > diff --git

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Constify load detect mode

On Thu, May 18, 2017 at 10:38:37PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Make the mode used for load detection const, and adjust all relevant > functions to accept a const mode. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Consitfy mode parameter to drm_atomic_set_mode_for_crtc()

On Thu, May 18, 2017 at 10:38:36PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > drm_atomic_set_mode_for_crtc() doesn't modify the passed mode, so let's > make it const. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Compute the fw_domain id from the mask

On 15/05/2017 11:45, Chris Wilson wrote: On Mon, May 15, 2017 at 11:18:11AM +0100, Tvrtko Ursulin wrote: On 12/05/2017 14:53, Chris Wilson wrote: Storing both the mask and the id is redundant as we can trivially compute one from the other. As the mask is more frequently used, remove the id.

[Intel-gfx] [PATCH v3] drm/i915: Enable guest i915 full ppgtt functionality

Enable the guest i915 full ppgtt functionality when host can provide this capability. vgt_caps is introduced to guest i915 driver to get the vgpu capabilities from the device model. VGT_CPAS_FULL_PPGTT is one of the capabilities type to let guest i915 dirver know that the guest i915 full ppgtt is

Re: [Intel-gfx] [PATCH] drm/i915: Encourage our shrinker more when our shmemfs allocations fails

On la, 2017-05-20 at 10:33 +0100, Chris Wilson wrote: > Commit 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than > incur the oom for gfx allocations") made the bold decision to try and > avoid the oomkiller by reporting -ENOMEM to userspace if our allocation > failed after attempting to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Fix deadlock retry loop in page_flip_ioctl

== Series Details == Series: drm: Fix deadlock retry loop in page_flip_ioctl URL : https://patchwork.freedesktop.org/series/24773/ State : success == Summary == Series 24773v1 drm: Fix deadlock retry loop in page_flip_ioctl

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enable guest i915 full ppgtt functionality

== Series Details == Series: drm/i915: Enable guest i915 full ppgtt functionality URL : https://patchwork.freedesktop.org/series/24774/ State : success == Summary == Series 24774v1 drm/i915: Enable guest i915 full ppgtt functionality

Re: [Intel-gfx] [PATCH] drm/i915/huc: Update GLK HuC version

On Thu, 2017-05-18 at 10:47 -0700, Anusha Srivatsa wrote: > Update version of HuC from 01.07.1748 to the > version 02.00.1748 > > Cc: Ander Conselvan > Cc: John Spotswood > Signed-off-by: Anusha Srivatsa

Re: [Intel-gfx] [PATCH v4 2/2] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI

On Fri, May 19, 2017 at 04:50:17PM -0400, Robert Foss wrote: > Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI > as a convenience. > > Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up > through the atomic API, but realizing that userspace is likely to take >

[Intel-gfx] [PATCH] drm: Fix deadlock retry loop in page_flip_ioctl

I failed to properly onion-wrap the unwind code: We acquire the vblank reference before we start with the wait-wound locking dance, hence we must make sure we retry before we drop the reference. Oops. Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl") Cc: Harry Wentland

[Intel-gfx] [PATCH v3] drm/i915: Use a cached mapping for the physical HWS

Older gen use a physical address for the hardware status page, for which we use cache-coherent writes. As the writes are into the cpu cache, we use a normal WB mapped page to read the HWS, used for our seqno tracking. Anecdotally, I observed lost breadcrumbs writes into the HWS on i965gm, which

[Intel-gfx] [PATCH] drm/i915/selftests: Silence compiler warning in igt_ctx_exec

The compiler doesn't always spot the guard that object is allocated on the first pass, leading to: drivers/gpu/drm/i915/selftests/i915_gem_context.c: warning: 'obj' may be used uninitialized in this function [-Wuninitialized]: => 370:8 Reported-by: Geert Uytterhoeven

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/huc: Update GLK HuC version

On Thu, 2017-05-18 at 18:06 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/huc: Update GLK HuC version > URL : https://patchwork.freedesktop.org/series/24641/ > State : success Pushed, thanks for the patch. Ander > > == Summary == > > Series 24641v1 drm/i915/huc:

Re: [Intel-gfx] [PATCH v4 1/2] drm/blend: Fix comment typ-o

On Fri, May 19, 2017 at 04:50:16PM -0400, Robert Foss wrote: > Fix DRM_REFELCT_Y -> DRM_REFLECT_Y. > > Signed-off-by: Robert Foss Applied, thanks. -Daniel > --- > drivers/gpu/drm/drm_blend.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep the forcewake timer alive for 1ms past the most recent use

On 15/05/2017 13:35, Chris Wilson wrote: On Mon, May 15, 2017 at 01:06:47PM +0100, Tvrtko Ursulin wrote: On 15/05/2017 11:41, Chris Wilson wrote: On Mon, May 15, 2017 at 11:14:32AM +0100, Tvrtko Ursulin wrote: On 12/05/2017 23:16, Chris Wilson wrote: Currently the timer is armed for 1ms

Re: [Intel-gfx] [PATCH] drm/i915: Encourage our shrinker more when our shmemfs allocations fails

On Mon, May 22, 2017 at 11:23:58AM +0300, Joonas Lahtinen wrote: > On la, 2017-05-20 at 10:33 +0100, Chris Wilson wrote: > > Commit 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than > > incur the oom for gfx allocations") made the bold decision to try and > > avoid the oomkiller by

[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce buffer based cmd transport

== Series Details == Series: Introduce buffer based cmd transport URL : https://patchwork.freedesktop.org/series/24786/ State : success == Summary == Series 24786v1 Introduce buffer based cmd transport https://patchwork.freedesktop.org/api/1.0/series/24786/revisions/1/mbox/ fi-bdw-5557u

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/selftests: Silence compiler warning in igt_ctx_exec

== Series Details == Series: drm/i915/selftests: Silence compiler warning in igt_ctx_exec URL : https://patchwork.freedesktop.org/series/24787/ State : warning == Summary == Series 24787v1 drm/i915/selftests: Silence compiler warning in igt_ctx_exec

Re: [Intel-gfx] [PATCH 44/67] drm/i915/cnl: DC3 to DC5 counters available on CNL.

On 4/7/2017 12:45 AM, Rodrigo Vivi wrote: There is no confirmation if the DC5 to DC6 is available on CNL though. But I could see DC3 to DC5 counter increasing reliably. So let's at least add this one. Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH] drm/i915: Allow kswapd to pause the device whilst reaping

In commit 5763ff04dc4e ("drm/i915: Avoid GPU stalls from kswapd") we stopped direct reclaim and kswapd from triggering GPU/client stalls whilst running (by restricting the objects they could reap to be idle). However with abusive GPU usage, it becomes quite easy to starve kswapd of memory and

Re: [Intel-gfx] [PATCH] drm/i915: Use a cached mapping for the physical HWS

On Mon, May 22, 2017 at 10:55:01AM +0200, Daniel Vetter wrote: > On Wed, May 17, 2017 at 02:02:50PM +0100, Chris Wilson wrote: > > Older gen use a physical address for the hardware status page, for which > > we use cache-coherent writes. As the writes are into the cpu cache, we use > > a normal WB

Re: [Intel-gfx] [PATCH v5] dma-buf/sync-file: Defer creation of sync_file->name

On Tue, May 16, 2017 at 12:10:42PM +0100, Chris Wilson wrote: > Constructing the name takes the majority of the time for allocating a > sync_file to wrap a fence, and the name is very rarely used (only via > the sync_file status user interface). To reduce the impact on the common > path (that of

Re: [Intel-gfx] [PATCH igt] intel-ci: Add gem_exec_reloc/basic-range to BAT

On Mon, May 15, 2017 at 04:03:50PM +0200, Daniel Vetter wrote: > What would probably help the CI folks is a gem testcase list that includes > all the important stuff (so much more than BAT), but also completes in a > reasonable amount of time (2h as a goal might be good). Atm not even > excluding

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen3: Improve reset reliability

== Series Details == Series: drm/i915/gen3: Improve reset reliability URL : https://patchwork.freedesktop.org/series/24777/ State : success == Summary == Series 24777v1 drm/i915/gen3: Improve reset reliability https://patchwork.freedesktop.org/api/1.0/series/24777/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH 43/67] drm/i915: Use HAS_CSR instead of gen number on DMC load.

On 4/7/2017 12:45 AM, Rodrigo Vivi wrote: Since we have HAS_CSR tied to the platform definition let's use this instead of checking per platform. One less thing to worry when adding support to new platforms. Signed-off-by: Rodrigo Vivi ---

[Intel-gfx] [CI v2 1/2] drm/i915/guc: Disable send function on fini

In earlier patch 789a625 we were enabling send function only after successful init. For completeness, we should make sure that we disable it on fini. v2: don't group steps by submission flag (Chris) Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen

[Intel-gfx] [CI v2 2/2] drm/i915/guc: Introduce buffer based cmd transport

Buffer based command transport can replace MMIO based mechanism. It may be used to perform host-2-guc and guc-to-host communication. Portions of this patch are based on work by: Michel Thierry Robert Beckett Daniele Ceraolo Spurio

[Intel-gfx] [CI v2 0/2] Introduce buffer based cmd transport

This series is same as [1] but this time without enabling GuC submission, as Guc submission is not working due to other changes. [1] https://patchwork.freedesktop.org/series/24715/ Michal Wajdeczko (2): drm/i915/guc: Disable send function on fini drm/i915/guc: Introduce buffer based cmd

Re: [Intel-gfx] [PATCH] drm/i915: Use a cached mapping for the physical HWS

On Wed, May 17, 2017 at 02:02:50PM +0100, Chris Wilson wrote: > Older gen use a physical address for the hardware status page, for which > we use cache-coherent writes. As the writes are into the cpu cache, we use > a normal WB mapped page to read the HWS, used for our seqno tracking. > >

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Restore lost "Initialized i915" welcome message"

On Wed, May 17, 2017 at 11:12:28AM -0300, Gabriel Krisman Bertazi wrote: > Daniel Vetter writes: > > > This reverts commit bc5ca47c0af4f949ba889e666b7da65569e36093. > > > > Gabriel put this back into generic code with > > > > commit

[Intel-gfx] [PATCH] drm/i915/gen3: Improve reset reliability

We improved the reset reliablity on gen4 with stopping all engines before commencing reset, in commit 2c80353f3cd0 ("drm/i915/g4x: Improve gpu reset reliability") Evidence indicates that this same trick works with gen3. Testcase: igt/gem_busy/*-hang #blb-e6850 Cc: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow kswapd to pause the device whilst reaping

== Series Details == Series: drm/i915: Allow kswapd to pause the device whilst reaping URL : https://patchwork.freedesktop.org/series/24776/ State : success == Summary == Series 24776v1 drm/i915: Allow kswapd to pause the device whilst reaping

Re: [Intel-gfx] [PATCH] drm/i915/gen3: Improve reset reliability

On Mon, May 22, 2017 at 12:02:44PM +0300, Mika Kuoppala wrote: > We improved the reset reliablity on gen4 with > stopping all engines before commencing reset, in > commit 2c80353f3cd0 ("drm/i915/g4x: Improve gpu reset reliability") > > Evidence indicates that this same trick works with gen3.

Re: [Intel-gfx] [PATCH igt] intel-ci: Add gem_exec_reloc/basic-range to BAT

On Mon, May 15, 2017 at 04:03:50PM +0200, Daniel Vetter wrote: > On Thu, May 11, 2017 at 12:13:44AM +0100, Chris Wilson wrote: > > We have no coverage of sign-extended relocations in BAT, so provide > > some. > > > > Signed-off-by: Chris Wilson > > Cc: Petri Latvala

Re: [Intel-gfx] [PATCH] drm: Fix deadlock retry loop in page_flip_ioctl

On 22/05/17 04:31 PM, Daniel Vetter wrote: > I failed to properly onion-wrap the unwind code: We acquire the vblank > reference before we start with the wait-wound locking dance, hence we > must make sure we retry before we drop the reference. Oops. > > Fixes: 29dc0d1de182 ("drm: Roll out acquire

[Intel-gfx] [PATCH] drm/i915/gvt: remove redundant -Wall

This flag is already set in the top level Makefile of the kernel. Also, by having set CONFIG_DRM_I915_GVT, thereby appending -Wall to ccflags, you undo all the -Wno-* cflags previously set in the Make variable KBUILD_CFLAGS. For example: cc foo.c -Wall -Wno-format -Wall resets -Wformat.

[Intel-gfx] [PATCH] drm/i915: mark wait_for_engine() __maybe_unused

This solves a warning when compiling the driver with Clang, -Werror enabled, and CONFIG_DRM_I915_DEBUG_GEM unset, since Clang warns that: drivers/gpu/drm/i915/i915_gem.c:3274:12: error: function 'wait_for_engine' is not needed and will not be emitted

[Intel-gfx] [PATCH v3 1/5] drm/i915/gvt: Extend the GVT-g architecture to support vfio device region

Signed-off-by: Xiaoguang Chen --- drivers/gpu/drm/i915/gvt/kvmgt.c | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index 1ae0b40..3c6a02b 100644 ---

[Intel-gfx] [PATCH v3 3/5] drm/i915/gvt: Frame buffer decoder support for GVT-g

decode frambuffer attributes of primary, cursor and sprite plane Signed-off-by: Xiaoguang Chen --- drivers/gpu/drm/i915/gvt/Makefile | 3 +- drivers/gpu/drm/i915/gvt/display.c| 2 +- drivers/gpu/drm/i915/gvt/display.h| 2 +

[Intel-gfx] [PATCH v3 2/5] drm/i915/gvt: OpRegion support for GVT-g

OpRegion is needed to support display related operation for intel vgpu. A vfio device region is added to intel vgpu to deliver the host OpRegion information to user space so user space can construct the OpRegion for vgpu. Signed-off-by: Bing Niu Signed-off-by: Xiaoguang Chen

[Intel-gfx] [PATCH v3 4/5] drm/i915/gvt: Dmabuf support for GVT-g

dmabuf for GVT-g can be exported to users who can use the dmabuf to show the desktop of vm which use intel vgpu. Currently we provide query and create new dmabuf operations. Users of dmabuf can cache some created dmabufs and related information such as the framebuffer's address, size, tiling

[Intel-gfx] [PATCH v3 5/5] drm/i915/gvt: Adding interface so user space can get the dma-buf

User space will try to create a management fd for the dma-buf operation. Using this management fd user can query the plane information and create a dma-buf fd if necessary. GVT-g will handle the life cycle of the management fd and will align the life cycle of the fd with the vfio device. User

[Intel-gfx] [PATCH v3 0/5] drm/i915/gvt: Dma-buf support for GVT-g

v2->v3: 1) add a field gvt_plane_info in the drm_i915_gem_obj structure to save the decoded plane information to avoid look up while need the plane info. 2) declare a new flag I915_GEM_OBJECT_IS_GVT_DMABUF in drm_i915_gem_object to represent the gem obj for gvt's dma-buf. The tiling mode, caching

Re: [Intel-gfx] [PATCH v5] drm/i915/gvt: return the correct usable aperture size under gvt environment

On 2017.05.19 23:35:03 +0800, Weinan Li wrote: > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace. > In gvt environment, each vm only use the ballooned part of aperture, so we > should return the correct available aperture size exclude the reserved part > by balloon. pls

Re: [Intel-gfx] [PATCH 42/67] drm/i915/DMC/CNL: Load DMC on CNL

On 4/7/2017 12:45 AM, Rodrigo Vivi wrote: From: Anusha Srivatsa This patch loads the DMC on CNL.The firmware version is 1.04. v2: (Rodrigo) Remove MODULE_FIRMWARE. Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: remove redundant -Wall

== Series Details == Series: drm/i915/gvt: remove redundant -Wall URL : https://patchwork.freedesktop.org/series/24779/ State : success == Summary == Series 24779v1 drm/i915/gvt: remove redundant -Wall https://patchwork.freedesktop.org/api/1.0/series/24779/revisions/1/mbox/ fi-bdw-5557u

Re: [Intel-gfx] [PATCH 23/24] drm/i915: Keep a recent cache of freed contexts objects for reuse

On Mon, May 22, 2017 at 11:51:27AM +0100, Tvrtko Ursulin wrote: > > On 18/05/2017 10:46, Chris Wilson wrote: > >Keep the recently freed context objects for reuse. This allows us to use > >the current GGTT bindings and dma bound pages, avoiding any clflushes as > >required. We mark the objects as

  1   2   >