[Intel-gfx] [PATCH] drm/i915/gvt: add pcode read/write emulation of BDW

Add pcode read/write emulation in gvt for BDW. Signed-off-by: Weinan Li --- drivers/gpu/drm/i915/gvt/handlers.c | 33 ++--- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/handlers.c

[Intel-gfx] [GIT PULL] more GVT-g fixes for 4.11

Hi, This pull includes latest GVT-g fixes for 4.11 to resolve stablity and usability issues found during co-debugging with distribution developers which improves a lot. Thanks. --- The following changes since commit 4a0b3444da3ce1090d0f894f4e343756a94ab8c3: drm/i915/gvt: return error code if

Re: [Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

Reviewed-by: Sagar Arun Kamble On 2/24/2017 4:41 AM, Michel Thierry wrote: There was no way to check if the platform is running the latest firmware. Cc: Tvrtko Ursulin Cc: Arkadiusz Hiler Signed-off-by: Michel

Re: [Intel-gfx] [RFC 06/11] drm/i915/guc: Remove extra arguments from guc_client_alloc

On 23/02/17 08:38, Oscar Mateo wrote: On 02/23/2017 11:14 AM, Michał Winiarski wrote: We're always using all engines and kernel context for guc clients, let's remove those arguments from guc_client_alloc. I am quite new to the GuC but, by the look of it, passing the ctx was groundwork for

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

On Thu, 2017-02-16 at 09:09 +, Lankhorst, Maarten wrote: > Daniel Vetter schreef op di 14-02-2017 om 20:51 [+0100]: > > On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran > > wrote: > > > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote: > > > >

Re: [Intel-gfx] [RFC 06/11] drm/i915/guc: Remove extra arguments from guc_client_alloc

On 02/23/2017 11:14 AM, Michał Winiarski wrote: We're always using all engines and kernel context for guc clients, let's remove those arguments from guc_client_alloc. I am quite new to the GuC but, by the look of it, passing the ctx was groundwork for direct submission (which means calling

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Include GuC fw version in error state

== Series Details == Series: drm/i915: Include GuC fw version in error state URL : https://patchwork.freedesktop.org/series/20181/ State : success == Summary == Series 20181v1 drm/i915: Include GuC fw version in error state

Re: [Intel-gfx] [RFC 1/3] drm/i915: Watchdog timeout: IRQ handler for gen8+

On Thu, Feb 23, 2017 at 08:57:54PM +, Chris Wilson wrote: > On Thu, Feb 23, 2017 at 11:44:17AM -0800, Michel Thierry wrote: > > + > > + /* Make sure the active request will be marked as guilty */ > > + engine->hangcheck.stalled = true; > > +

[Intel-gfx] [PATCH] drm/i915: Include GuC fw version in error state

There was no way to check if the platform is running the latest firmware. Cc: Tvrtko Ursulin Cc: Arkadiusz Hiler Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_gpu_error.c | 10 ++ 1 file

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/drv_hangman: watchdog tests

On Thu, Feb 23, 2017 at 10:26:29PM +, Chris Wilson wrote: > On Thu, Feb 23, 2017 at 11:44:21AM -0800, Michel Thierry wrote: > > Test watchdog triggered resets. > > How about setting a watchdog N with a dummy load set to expire in 2N > (where 2N is less 1s to avoid hangcheck). Then check fence

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/chamelium: Don't sleep so much in basic hpd tests

On Thu, Feb 23, 2017 at 03:31:09PM -0500, Lyude Paul wrote: > On Thu, 2017-02-23 at 07:26 +, Chris Wilson wrote: > > On Wed, Feb 22, 2017 at 10:18:33PM -0500, Lyude wrote: > > > Now that we can just disable HPD storm detection, there's no need > > > to > > > sleep between each hotplug cycle. >

Re: [Intel-gfx] [PATCH] drm/i915: Suppress fbc suggestion to increase stolen if disabled

On Thu, Feb 23, 2017 at 05:39:24PM +, Vivi, Rodrigo wrote: > Reviewed-by: Rodrigo Vivi Thanks, applied. Just noticed the odd message when browsing the gvt logs. -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/drv_hangman: watchdog tests

On Thu, Feb 23, 2017 at 11:44:21AM -0800, Michel Thierry wrote: > Test watchdog triggered resets. How about setting a watchdog N with a dummy load set to expire in 2N (where 2N is less 1s to avoid hangcheck). Then check fence status to ensure watchdog kicked the batch. See gem_exec_fence. -Chris

Re: [Intel-gfx] [RFC 1/3] drm/i915: Watchdog timeout: IRQ handler for gen8+

On 23/02/17 13:49, Chris Wilson wrote: On Thu, Feb 23, 2017 at 01:21:03PM -0800, Michel Thierry wrote: On 23/02/17 12:57, Chris Wilson wrote: On Thu, Feb 23, 2017 at 11:44:17AM -0800, Michel Thierry wrote: *** General *** Watchdog timeout (or "media engine reset") is a feature that

Re: [Intel-gfx] [RFC 1/3] drm/i915: Watchdog timeout: IRQ handler for gen8+

On Thu, Feb 23, 2017 at 01:21:03PM -0800, Michel Thierry wrote: > > > On 23/02/17 12:57, Chris Wilson wrote: > >On Thu, Feb 23, 2017 at 11:44:17AM -0800, Michel Thierry wrote: > >>*** General *** > >> > >>Watchdog timeout (or "media engine reset") is a feature that allows > >>userland

Re: [Intel-gfx] [RFC 04/11] drm/i915/preempt: Implement null preemption method

On Thu, Feb 23, 2017 at 08:08:26PM +0100, Michał Winiarski wrote: > +static void __execlists_try_preempt(struct intel_engine_cs *engine, > + int prio) > +{ > + struct drm_i915_gem_request *rq; > + int highest_prio = INT_MIN; > + int ret; > + > +

Re: [Intel-gfx] [RFC 01/11] drm/i915/scheduler: Remember request priority throughout its lifetime

On Thu, Feb 23, 2017 at 08:08:23PM +0100, Michał Winiarski wrote: > Since request can be cancelled, we need to avoid overriding its priority > during submission to be able to resubmit it. And this breaks rescheduling. -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [RFC 1/3] drm/i915: Watchdog timeout: IRQ handler for gen8+

On 23/02/17 12:57, Chris Wilson wrote: On Thu, Feb 23, 2017 at 11:44:17AM -0800, Michel Thierry wrote: *** 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

Re: [Intel-gfx] [RFC 3/3] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

On Thu, Feb 23, 2017 at 11:44:19AM -0800, Michel Thierry wrote: > Final enablement patch for GPU hang detection using watchdog timeout. > Using the gem_context_setparam ioctl, users can specify the desired > timeout value in milliseconds, and the driver will do the conversion to > 'timestamps'. >

Re: [Intel-gfx] [RFC 2/3] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+

On Thu, Feb 23, 2017 at 11:44:18AM -0800, Michel Thierry wrote: > Emit the required commands into the ring buffer for starting and > stopping the watchdog timer before/after batch buffer start during > batch buffer submission. > > Signed-off-by: Tomas Elf > Signed-off-by:

Re: [Intel-gfx] [RFC 1/3] drm/i915: Watchdog timeout: IRQ handler for gen8+

On Thu, Feb 23, 2017 at 11:44:17AM -0800, Michel Thierry wrote: > *** 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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/3] drm/i915: Watchdog timeout: IRQ handler for gen8+

== Series Details == Series: series starting with [RFC,1/3] drm/i915: Watchdog timeout: IRQ handler for gen8+ URL : https://patchwork.freedesktop.org/series/20173/ State : success == Summary == Series 20173v1 Series without cover letter

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/chamelium: Don't sleep so much in basic hpd tests

On Thu, 2017-02-23 at 07:26 +, Chris Wilson wrote: > On Wed, Feb 22, 2017 at 10:18:33PM -0500, Lyude wrote: > > Now that we can just disable HPD storm detection, there's no need > > to > > sleep between each hotplug cycle. > > > > Signed-off-by: Lyude > > --- > >  

Re: [Intel-gfx] [PATCH 1/3] drm/atomic: Make disable_all helper fully disable the crtc.

Op 23-02-17 om 16:03 schreef Sean Paul: > On Tue, Feb 21, 2017 at 02:51:40PM +0100, Maarten Lankhorst wrote: >> It seems that nouveau requires this, so best to do this in the helper. >> This allows nouveau to use the atomic suspend helper. > Pardon the stupid question, but why can't nouveau just

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Refactor code to select the DDI buf translation table (rev2)

== Series Details == Series: series starting with [1/3] drm/i915: Refactor code to select the DDI buf translation table (rev2) URL : https://patchwork.freedesktop.org/series/20165/ State : success == Summary == Series 20165v2 Series without cover letter

[Intel-gfx] [RFC 2/3] 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. Signed-off-by: Tomas Elf Signed-off-by: Ian Lister Signed-off-by: Arun Siluvery

[Intel-gfx] [RFC 1/3] 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] [RFC 3/3] 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 milliseconds, and the driver will do the conversion to 'timestamps'. The _recommended_ default watchdog threshold for video engines is 60 ms,

[Intel-gfx] [PATCH i-g-t 2/2] tests/drv_hangman: watchdog tests

Test watchdog triggered resets. Signed-off-by: Michel Thierry --- tests/drv_hangman.c | 30 +- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c index 51bdbdaa..ba230f65 100644 ---

[Intel-gfx] [PATCH i-g-t 1/2] lib/igt_gt: Add watchdog gem_ctx_set_param ioctl interface

Set a watchdog timeout value in a given context. Signed-off-by: Michel Thierry --- lib/igt_gt.c | 7 +++ lib/igt_gt.h | 1 + 2 files changed, 8 insertions(+) diff --git a/lib/igt_gt.c b/lib/igt_gt.c index 3bfaf2e4..e30385ec 100644 --- a/lib/igt_gt.c +++

Re: [Intel-gfx] [PATCH] drm/i915: Split I915_RESET_IN_PROGRESS into two flags

On 23/02/17 08:59, Chris Wilson wrote: I915_RESET_IN_PROGRESS is being used for both signaling the requirement to i915_mutex_lock_interruptible() to avoid taking the struct_mutex and to instruct a waiter (already holding the struct_mutex) to perform the reset. To allow for a little more

[Intel-gfx] [RFC 10/11] drm/i915/preempt: Emit MI_ARB_CHECK before the start of user batch

We should probably do this conditionally, based on whether preemption is actually enabled. Signed-off-by: Michał Winiarski --- drivers/gpu/drm/i915/intel_lrc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c

[Intel-gfx] [RFC 11/11] drm/i915/preempt: Show engine preempt state in engine_info debugfs

Signed-off-by: Michał Winiarski --- drivers/gpu/drm/i915/i915_debugfs.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 10490bf..b71420c 100644 ---

[Intel-gfx] [RFC 09/11] HACK drm/i915/preempt: Actually send the preemption request

Now that we're able to post-process the preemption event, let's actually send it to GuC. To identify that preemption has finished, we're using a dummy request sent through kernel_context. Signed-off-by: Michał Winiarski --- drivers/gpu/drm/i915/i915_guc_submission.c

[Intel-gfx] [RFC 07/11] drm/i915/guc: Add a second client, to be used for preemption

From: Dave Gordon This second client is created with priority KMD_HIGH, and marked as preemptive. v2: Rebase, cleanup, use an array for the second client. Signed-off-by: Dave Gordon Signed-off-by: Michał Winiarski

[Intel-gfx] [RFC 08/11] drm/i915/guc: Add preemption action to GuC firmware interface

Signed-off-by: Michał Winiarski --- drivers/gpu/drm/i915/intel_guc_fwif.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h b/drivers/gpu/drm/i915/intel_guc_fwif.h index 25691f0..5b79ce0 100644 ---

[Intel-gfx] [RFC 06/11] drm/i915/guc: Remove extra arguments from guc_client_alloc

We're always using all engines and kernel context for guc clients, let's remove those arguments from guc_client_alloc. Signed-off-by: Michał Winiarski --- drivers/gpu/drm/i915/i915_guc_submission.c | 16 1 file changed, 4 insertions(+), 12

[Intel-gfx] [RFC 05/11] drm/i915/preempt: Handle preemption event in guc tasklet

We need to avoid sending new work if the preemption is in progress. Once it finished, we need to identify and unsubmit the preempted workload, submit new workload (potentially the one responsible for preemption) and resubmit the preempted workload. Signed-off-by: Michał Winiarski

[Intel-gfx] [RFC 04/11] drm/i915/preempt: Implement null preemption method

We're only requesting preemption for requests that have high enough priority (above threshold). Currently we're also ignoring requests that have dependencies on different engines. Signed-off-by: Michał Winiarski --- drivers/gpu/drm/i915/i915_guc_submission.c | 3 ++

[Intel-gfx] [RFC 03/11] drm/i915/preempt: Add information needed to track engine preempt state

We're using engine->preempt_requested to mark that preemption has started, and new hws entry allowing HW to mark that preemption has finished and the engine is idle, allowing us to do the postprocessing. Signed-off-by: Michał Winiarski ---

[Intel-gfx] [RFC 02/11] drm/i915/preempt: Add module parameter for preemption

We're going to support preemption on platforms where GuC submission is enabled. Signed-off-by: Michał Winiarski --- drivers/gpu/drm/i915/i915_drv.c| 6 ++ drivers/gpu/drm/i915/i915_drv.h| 3 +++ drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [RFC 01/11] drm/i915/scheduler: Remember request priority throughout its lifetime

Since request can be cancelled, we need to avoid overriding its priority during submission to be able to resubmit it. Signed-off-by: Michał Winiarski --- drivers/gpu/drm/i915/i915_guc_submission.c | 1 - drivers/gpu/drm/i915/intel_lrc.c | 1 - 2 files

[Intel-gfx] [RFC] GuC based preemption

Now that we're able to unsubmit requests, let's try to actually preempt. The series is partially based on "Preemption support for GPU scheduler": https://lists.freedesktop.org/archives/intel-gfx/2015-December/082817.html It requires "drm/i915/scheduler: Support user-defined priorities" It's

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Split I915_RESET_IN_PROGRESS into two flags

== Series Details == Series: drm/i915: Split I915_RESET_IN_PROGRESS into two flags URL : https://patchwork.freedesktop.org/series/20162/ State : success == Summary == Series 20162v1 drm/i915: Split I915_RESET_IN_PROGRESS into two flags

Re: [Intel-gfx] [PATCH] drm: Add name for DRM_DP_DUAL_MODE_LSPCON

On Wed, Feb 22, 2017 at 02:59:28PM +0200, Ander Conselvan de Oliveira wrote: > Handle DRM_DP_DUAL_MODE_LSPCON in drm_dp_get_dual_mode_type_name(), > otherwise a call to that function can theoretically trigger a WARN. > > Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") > Cc:

Re: [Intel-gfx] [PATCH v2] drm/i915/lspcon: Switch back to PCON mode after output replug

On Wed, Feb 22, 2017 at 05:10:52PM +0200, Imre Deak wrote: > At least a ParadTech PS175 LSPCON chip/firmware uses long instead of > short pulses to signal output unplug/plug events. This is contrary to > how branch devices normally work which use short HPD signaling. This > chip will also switch

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Remove redundant TLB invalidate on switching contexts

== Series Details == Series: series starting with [1/5] drm/i915: Remove redundant TLB invalidate on switching contexts URL : https://patchwork.freedesktop.org/series/20155/ State : success == Summary == Series 20155v1 Series without cover letter

[Intel-gfx] [PATCH v2 3/3] drm/i915: Introduce intel_ddi_dp_voltage_max()

From: Ville Syrjälä Rather than sprinkling ideas of how big the DDI buf translation tables are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c where the actual tables are defined. To that end we introduce intel_ddi_dp_voltage_max() which will

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Refactor code to select the DDI buf translation table

On Thu, Feb 23, 2017 at 07:35:05PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Split the code to select the correct trasnslation table into DP, translations, superfluous space before DP > eDP and FDI specific helpers. This reduces the

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Introduce intel_ddi_dp_voltage_max()

On Thu, Feb 23, 2017 at 07:44:48PM +0200, David Weinehall wrote: > On Thu, Feb 23, 2017 at 07:35:07PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Rather than sprinkling ideas of how big the DDI buf translation tables > > are

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Refactor translate_signal_level()

On Thu, Feb 23, 2017 at 07:43:52PM +0200, David Weinehall wrote: > On Thu, Feb 23, 2017 at 07:35:06PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Convert the big switch statement in translate_signal_level() into a neat > > table. The

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Introduce intel_ddi_dp_voltage_max()

On Thu, Feb 23, 2017 at 07:35:07PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Rather than sprinkling ideas of how big the DDI buf translation tables > are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c > where the actual

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Refactor translate_signal_level()

On Thu, Feb 23, 2017 at 07:35:06PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Convert the big switch statement in translate_signal_level() into a neat > table. The table also serves as documentation for the translation > tables. We'll

Re: [Intel-gfx] [PATCH] drm/i915: Suppress fbc suggestion to increase stolen if disabled

Reviewed-by: Rodrigo Vivi On Thu, 2017-02-23 at 12:20 +, Chris Wilson wrote: > If the reserved region of memory has not been setup (most probably > because it has been limited by hardware or virtualisation), don't tell > the user to try and increase the amount of

[Intel-gfx] [PATCH 3/3] drm/i915: Introduce intel_ddi_dp_voltage_max()

From: Ville Syrjälä Rather than sprinkling ideas of how big the DDI buf translation tables are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c where the actual tables are defined. To that end we introduce intel_ddi_dp_voltage_max() which will

[Intel-gfx] [PATCH 2/3] drm/i915: Refactor translate_signal_level()

From: Ville Syrjälä Convert the big switch statement in translate_signal_level() into a neat table. The table also serves as documentation for the translation tables. We'll also have other uses for this table later on. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 1/3] drm/i915: Refactor code to select the DDI buf translation table

From: Ville Syrjälä Split the code to select the correct trasnslation table into DP, eDP and FDI specific helpers. This reduces the clutter in intel_prepare_dp_ddi_buffers(), and we'll have other uses for some of these new helper functions later on.

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: signal first fence from irq handler if complete

== Series Details == Series: series starting with [v2,1/2] drm/i915: signal first fence from irq handler if complete URL : https://patchwork.freedesktop.org/series/20153/ State : failure == Summary == Series 20153v1 Series without cover letter

Re: [Intel-gfx] [RFC] drm/i915: Temporarily go realtime when polling PCODE

On Thu, Feb 23, 2017 at 01:00:32PM +, Tvrtko Ursulin wrote: > > On 23/02/2017 12:01, Imre Deak wrote: > >On Thu, Feb 23, 2017 at 09:37:29AM +, Tvrtko Ursulin wrote: > >>[...] > >>Having read the spec I think I see both sides now. > >> > >>Spec is actually suggesting we should busy-retry

[Intel-gfx] [PATCH] drm/i915: Split I915_RESET_IN_PROGRESS into two flags

I915_RESET_IN_PROGRESS is being used for both signaling the requirement to i915_mutex_lock_interruptible() to avoid taking the struct_mutex and to instruct a waiter (already holding the struct_mutex) to perform the reset. To allow for a little more coordination, split these two meaning into a

[Intel-gfx] [PATCH] drm/tinydrm: fix semicolon.cocci warnings

drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c:454:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Signed-off-by: Fengguang Wu --- tinydrm-helpers.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[Intel-gfx] [drm-intel:drm-intel-nightly 1827/1945] drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c:454:2-3: Unneeded semicolon

tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: 53a95c930ad728b11cc2b21e42b4bd9dcd306400 commit: 9f69eb5c36a644571cca6b2f8dc5f6a7cba04a8b [1827/1945] drm/tinydrm: Add helper functions coccinelle warnings: (new ones prefixed by >>) >>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Detect an out-of-order context switch

== Series Details == Series: drm/i915/execlists: Detect an out-of-order context switch URL : https://patchwork.freedesktop.org/series/20150/ State : success == Summary == Series 20150v1 drm/i915/execlists: Detect an out-of-order context switch

[Intel-gfx] [PATCH 09/15] drm/i915: Pass vma to relocate entry

We can simplify our tracking of pending writes in an execbuf to the single bit in the vma->exec_entry->flags, but that requires the relocation function knowing the object's vma. Pass it along. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c |

[Intel-gfx] [PATCH 15/15] drm/i915: Async GPU relocation processing

If the user requires patching of their batch or auxiliary buffers, we currently make the alterations on the cpu. If they are active on the GPU at the time, we wait under the struct_mutex for them to finish executing before we rewrite the contents. This happens if shared relocation trees are used

[Intel-gfx] [PATCH 07/15] drm/i915: Stop using obj->obj_exec_link outside of execbuf

i915_gem_stolen_list_info() sneakily takes advantage of the obj->obj_exec_link to save itself from having to allocate. Enough of the subterfuge, just allocate an array of pointers and sort them instead of the list. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 13/15] drm/i915: Remove superfluous i915_add_request_no_flush() helper

The only time we need to emit a flush inside request emission is after an execbuffer, for which we can use the full __i915_add_request(). All other instances want the simpler i915_add_request() without flushing, so remove the useless helper. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 05/15] drm/i915: Use vma->exec_entry as our double-entry placeholder

This has the benefit of not requiring us to manipulate the vma->exec_link list when tearing down the execbuffer, and is a marginally cheaper test to detect the user error. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_evict.c | 17 ++-

[Intel-gfx] [PATCH 10/15] drm/i915: Eliminate lots of iterations over the execobjects array

The major scaling bottleneck in execbuffer is the processing of the execobjects. Creating an auxiliary list is inefficient when compared to using the execobject array we already have allocated. Reservation is then split into phases. As we lookup up the VMA, we try and bind it back into active

[Intel-gfx] [PATCH 14/15] drm/i915: Allow execbuffer to use the first object as the batch

Currently, the last object in the execlist is the always the batch. However, when building the batch buffer we often know the batch object first and if we can use the first slot in the execlist we can emit relocation instructions relative to it immediately and avoid a separate pass to adjust the

[Intel-gfx] [PATCH 11/15] drm/i915: First try the previous execbuffer location

When choosing a slot for an execbuffer, we ideally want to use the same address as last time (so that we don't have to rebind it) and the same address as expected by the user (so that we don't have to fixup any relocations pointing to it). If we first try to bind the incoming execbuffer->offset

[Intel-gfx] [PATCH 03/15] drm/i915: Drop spinlocks around adding to the client request list

Adding to the tail of the client request list as the only other user is in the throttle ioctl that iterates forwards over the list. It only needs protection against deletion of a request as it reads it, it simply won't see a new request added to the end of the list, or it would be too early and

[Intel-gfx] [PATCH 02/15] drm/i915: Retire an active batch pool object rather than allocate new

Since obj->active_count is only updated upon retirement, if we see an active object in the batch pool, double check that is still active before deciding to allocate a new object. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_batch_pool.c | 37

[Intel-gfx] [PATCH 12/15] drm/i915: Wait upon userptr get-user-pages within execbuffer

This simply hides the EAGAIN caused by userptr when userspace causes resource contention. However, it is quite beneficial with highly contended userptr users as we avoid repeating the setup costs and kernel-user context switches. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 01/15] drm/i915: Copy user requested buffers into the error state

Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may use to indicate that it wants the contents of this buffer preserved in the error state (/sys/class/drm/cardN/error) following a GPU hang involving this batch. Use this at your discretion, the contents of the error state.

[Intel-gfx] [PATCH 08/15] drm/i915: Store a direct lookup from object handle to vma

The advent of full-ppgtt lead to an extra indirection between the object and its binding. That extra indirection has a noticeable impact on how fast we can convert from the user handles to our internal vma for execbuffer. In order to bypass the extra indirection, we use a resizable hashtable to

[Intel-gfx] Make execbuf fast[er]

Many eons ago, we add ppgtt support. Among the rejoicing, was a bitter pill, it was slow, much slower due to driver overhead in looking up the vma. In part this was due to obj_to_vma being a linear walk, but there was also the effect in execbuf of going from handle to obj to vma, and we have had

[Intel-gfx] [PATCH 04/15] drm/i915: Amalgamate execbuffer parameter structures

Combine the two slightly overlapping parameter structures we pass around the execbuffer routines into one. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 560 - 1 file changed, 238 insertions(+), 322

[Intel-gfx] [PATCH 06/15] drm/i915: Split vma exec_link/evict_link

Currently the vma has one link member that is used for both holding its place in the execbuf reservation list, and in any eviction list. This dual property is quite tricky and error prone. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_evict.c | 14

[Intel-gfx] [PATCH 4/5] drm/i915: Suppress context restore w/a when using MI_RESTORE_INHIBIT

If we are setting the context and do inhibit the restoration from the context image, also forgo applying the set-context w/a. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)

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

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 between Haswell context switches, bisecting to commit f9326be5f1d3 ("drm/i915: Rearrange

[Intel-gfx] [PATCH 1/5] drm/i915: Remove redundant TLB invalidate on switching contexts

We are required to reload the TLBs around context switches (MI_SET_CONTEXT specifically) and the recommendation is do that before the MI_SET_CONTEXT so that it is serialised with the switch and not forgotten: [DevSNB] If Flush TLB invalidation Mode is enabled it’s the driver’s responsibility to

[Intel-gfx] [PATCH 2/5] drm/i915: Remove redundant TLB invalidate on switching ppgtt

We are required to reload the TLBs around ppgtt switches. However, we already do an unconditional TLB invalidate before every batch and a flush afterwards, so this condition is already satisfied without extra flushes around the LRI instructions. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 3/5] drm/i915: Reduce context alignment

No hardware was ever shipped that needed more than 4096 byte alignment and future hardware will not use this legacy path. So reduce the alignment to make it easier and quicker to launch workloads. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c

[Intel-gfx] [PATCH v2 2/2] drm/i915: Delay disabling the user interrupt for breadcrumbs

A significant cost in setting up a wait is the overhead of enabling the interrupt. As we disable the interrupt whenever the queue of waiters is empty, if we are frequently waiting on alternating batches, we end up re-enabling the interrupt on a frequent basis. We do want to disable the interrupt

[Intel-gfx] [PATCH v2 1/2] drm/i915: signal first fence from irq handler if complete

As execlists and other non-semaphore multi-engine devices coordinate between engines using interrupts, we can shave off a few 10s of microsecond of scheduling latency by doing the fence signaling from the interrupt as opposed to a RT kthread. (Realistically the delay adds about 1% to an individual

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Add uncore mmio api for per-context registers

On Wed, Feb 22, 2017 at 04:36:31PM +, Robert Bragg wrote: > Since the exponent for periodic OA counter sampling is maintained in a > per-context register while we want to treat it as if it were global > state we need to be able to safely issue an mmio write to a per-context > register and

Re: [Intel-gfx] [PATCH 3/3] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb.

On Tue, Feb 21, 2017 at 02:51:42PM +0100, Maarten Lankhorst wrote: > This introduces a slight behavioral change to rmfb. Instead of > disabling a crtc when the primary plane is disabled, we try to > preserve it. > > Apart from old versions of the vmwgfx xorg driver, there is > nothing depending

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Defer unmasking RPS interrupts until after making adjustments

== Series Details == Series: drm/i915: Defer unmasking RPS interrupts until after making adjustments URL : https://patchwork.freedesktop.org/series/20148/ State : success == Summary == Series 20148v1 drm/i915: Defer unmasking RPS interrupts until after making adjustments

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,01/16] drm/i915: Check against the signaled bit for fences/requests

On Thu, Feb 23, 2017 at 08:18:10AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [v4,01/16] drm/i915: Check against the signaled > bit for fences/requests > URL : https://patchwork.freedesktop.org/series/20126/ > State : success > > == Summary == > > Series

Re: [Intel-gfx] [PATCH v4 5/6] drm/i915: enable scrambling

Think about two situations where:- - Monitor supports scrambling and scdc, but we will not enable it, as the current mode is 1080P@148 MHz - Monitor supports scrambling and scdc, and we will enable it, as the current mode is 4k@596 Mhz To differentiate between these two, we have:

Re: [Intel-gfx] [PATCH 2/3] drm: Convert drm_framebuffer_remove to atomic, v4.

On Tue, Feb 21, 2017 at 02:51:41PM +0100, Maarten Lankhorst wrote: > Instead of trying to do everything in 1 go, just do a basic safe > conversion first. We've been bitten by too many regressions in the > past. > > This patch only converts drm_framebuffer_remove to atomic. The > regression

Re: [Intel-gfx] [PATCH 1/3] drm/atomic: Make disable_all helper fully disable the crtc.

On Tue, Feb 21, 2017 at 02:51:40PM +0100, Maarten Lankhorst wrote: > It seems that nouveau requires this, so best to do this in the helper. > This allows nouveau to use the atomic suspend helper. Pardon the stupid question, but why can't nouveau just do the right thing when crtc_state->active

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Distinguish between timeout and error in sideband transactions

== Series Details == Series: drm/i915: Distinguish between timeout and error in sideband transactions URL : https://patchwork.freedesktop.org/series/20147/ State : warning == Summary == Series 20147v1 drm/i915: Distinguish between timeout and error in sideband transactions

[Intel-gfx] [PATCH] drm/i915/execlists: Detect an out-of-order context switch

We require that the request is completed before the context is switched away. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index

[Intel-gfx] [PATCH] drm/i915: Defer unmasking RPS interrupts until after making adjustments

To make our adjustments to RPS requires taking a mutex and potentially sleeping for an unknown duration - until we have completed our adjustments further RPS interrupts are immaterial (they are based on stale thresholds) and we can safely ignore them. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH] drm/i915: Distinguish between timeout and error in sideband transactions

After initiating a sideband transaction, we only want to wait for the transaction to become idle. If, as we are, we wait for both the busy and error flag to clear, if an error is raised we just spin until the timeout. Once the hw is idle, we can then check to see if the hw flagged an error, and

[Intel-gfx] [PATCH i-g-t] tests/kms_concurrent: Concurrent and interruptible subtests for atomic

This test case introduces concurrently running test cases for atomic modesetting. The first test or thread draws blue backround with black holes on it. These holes are covered by rectangular, blue planes that are placed randomly like in test case 'kms_plane_multiple'. The second thread changes

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for GLK plane/scaling fixes (rev2)

On Thu, 2017-02-23 at 07:52 +, Patchwork wrote: > == Series Details == > > Series: GLK plane/scaling fixes (rev2) > URL : https://patchwork.freedesktop.org/series/20051/ > State : success Pushed. Thanks for reviewing. Ander > > == Summary == > > Series 20051v2 GLK plane/scaling fixes >

Re: [Intel-gfx] [PATCH v4 5/6] drm/i915: enable scrambling

On Thu, Feb 23, 2017 at 03:07:40PM +0200, Ander Conselvan De Oliveira wrote: > On Thu, 2017-02-23 at 16:33 +0530, Sharma, Shashank wrote: > > Thanks for the review Ander, my comments, inline. > > > > > > Regards > > > > Shashank > > > > > > On 2/23/2017 1:33 PM, Ander Conselvan De Oliveira

  1   2   >