Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

I see. As long as amd can still just have kernel hiding unsupported mode by doing a pre-train I am okay with the proposal. Just to caution you the link training fallback we implemented on windows in old dal architecture is very painful to get right. Windows 7, 8.1 and 10 all behave

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

On Mon, Nov 14, 2016 at 11:31:11AM +, Tvrtko Ursulin wrote: > > On 14/11/2016 08:57, 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 v2 01/13] drm/i915/glk: Add Geminilake PCI IDs

I forgot to pass -1 to git send-email, that's why this patch ended up here. Please ignore. On Mon, 2016-11-14 at 16:24 +0200, Ander Conselvan de Oliveira wrote: > v2: Add new 0x3185 ID. (Joonas) > Signed-off-by: Ander Conselvan de Oliveira com> > Reviewed-by:

[Intel-gfx] [PATCH v3] drm/i915/glk: Introduce Geminilake platform definition

Geminilake is an Intel® Processor containing Intel® HD Graphics following Broxton. Let's start by adding the platform definition. PCI IDs and plaform specific code will follow. v2: Rebase (don't allow dev to be used with the new macro). v3: Update ddb size. (Matt) Rebase on

Re: [Intel-gfx] [PATCH v3 08/14] drm/i915/scheduler: Execute requests in order of priorities

On Mon, Nov 14, 2016 at 11:48:32AM +, Tvrtko Ursulin wrote: > > On 14/11/2016 11:41, Chris Wilson wrote: > >On Mon, Nov 14, 2016 at 11:15:52AM +, Tvrtko Ursulin wrote: > >>On 14/11/2016 08:56, Chris Wilson wrote: > >>>+static void execlists_schedule(struct drm_i915_gem_request *request,

[Intel-gfx] [PATCH v2 01/13] drm/i915/glk: Add Geminilake PCI IDs

v2: Add new 0x3185 ID. (Joonas) Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_pci.c | 1 + include/drm/i915_pciids.h | 4 2 files changed, 5 insertions(+) diff --git

[Intel-gfx] [PATCH v2] drm/i915: Create a common GEN9_LP_FEATURE.

From: Rodrigo Vivi The following LP platform inherits a lot of this platform So let's simplify here to re-use this later. v2: Keep ddb_size out of the new macro. Signed-off-by: Rodrigo Vivi Signed-off-by: Ander Conselvan de Oliveira

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Skip final clflush if LLC is coherent

On Mon, Nov 14, 2016 at 08:54:53AM +, Chris Wilson wrote: > If the LLC is coherent with the object, we do not need to worry about > whether main memory and cache mismatch when we hand the object back to > the system. > > Signed-off-by: Chris Wilson Makes sense to

Re: [Intel-gfx] [PATCH v3] Idleness DRRS test

On Mon, Nov 14, 2016 at 02:44:35PM +0200, Petri Latvala wrote: > Chris, happy with this revision? Me? No. It still uses a thread instead of events, so I don't think it qualifies as a good example for anyone else wanting to do the same thing. Lots of hardcoded expectations (specific sleep

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm_crtc.[hc] cleanup and documenation

== Series Details == Series: drm_crtc.[hc] cleanup and documenation URL : https://patchwork.freedesktop.org/series/15272/ State : warning == Summary == Series 15272v1 drm_crtc.[hc] cleanup and documenation https://patchwork.freedesktop.org/api/1.0/series/15272/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH v3] Idleness DRRS test

Chris, happy with this revision? On Fri, Oct 21, 2016 at 09:22:13AM +0530, Nautiyal Ankit wrote: > From: Ramalingam C > > Idleness DRRS: > By default the DRRS state will be at DRRS_HIGH_RR. When a Display > content is Idle for more than 1Sec Idleness will be

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm: Add missing mutex_destroy in drm_dev_init/release (rev2)

On to, 2016-11-10 at 14:16 +, Patchwork wrote: > == Series Details == > > Series: series starting with [v2] drm: Add missing mutex_destroy in > drm_dev_init/release (rev2) > URL   : https://patchwork.freedesktop.org/series/15110/ > State : success Daniel applied the other patch and I the

[Intel-gfx] ✗ Fi.CI.BAT: warning for dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence

== Series Details == Series: dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence URL : https://patchwork.freedesktop.org/series/15269/ State : warning == Summary == Series 15269v1 dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence

Re: [Intel-gfx] [PATCH] dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence

On Mon, Nov 14, 2016 at 11:55:40AM +, Chris Wilson wrote: > The current code is subject to a race where we may try to acquire a > reference on a stale fence: From i915.ko pov, this Fixes: d07f0e59b2c7 ("drm/i915: Move GEM activity tracking into a common struct reservation_object") -Chris --

[Intel-gfx] [PATCH 06/10] drm: Consolidate dumb buffer docs

Put the callback docs into struct drm_driver, and the small overview into a DOC comment. Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst | 42 ++--- drivers/gpu/drm/drm_dumb_buffers.c | 46

[Intel-gfx] [PATCH 10/10] drm: Drop externs from drm_crtc.h

Just noise. Signed-off-by: Daniel Vetter --- include/drm/drm_crtc.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index cf96b393091a..bcc1a4d1d1a6 100644 --- a/include/drm/drm_crtc.h

[Intel-gfx] [PATCH 09/10] drm: Move tile group code into drm_connector.c

And also put the overview section into the KMS Properties part of the docs, instead of randomly-placed within the helpers - this is part of the uabi. With this patch I think drm_crtc.[hc] is cleaned up and entirely documented. Signed-off-by: Daniel Vetter ---

[Intel-gfx] [PATCH 08/10] drm: Extract drm_mode_config.[hc]

And shuffle the kernel-doc structure a bit since drm_crtc.[hc] now only contains CRTC-related functions and structures. Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst | 32 +- drivers/gpu/drm/Makefile| 2 +-

[Intel-gfx] [PATCH 05/10] drm: Clean up kerneldoc for struct drm_driver

Just cleans up what's there, still plenty missing. Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-internals.rst | 3 + include/drm/drm_drv.h | 168 +++- 2 files changed, 109 insertions(+), 62 deletions(-) diff

[Intel-gfx] [PATCH 02/10] drm/i915: Fixup kerneldoc includes

Would be great if everony could add $ make DOCBOOKS="" htmldocs to their build scripts to catch these. 0day should also report them, not sure why it failed to spot this. Fixes: b42fe9ca0a1e ("drm/i915: Split out i915_vma.c") Cc: Tvrtko Ursulin Cc: Chris Wilson

[Intel-gfx] [PATCH 07/10] drm/print: Move kerneldoc next to definition

kerneldoc expects the comment next to definitions, otherwise it can't pick up exported vs. internal stuff. This fixes a warning from the doc build done with: $ make DOCBOOKS="" htmldocs Fixes: d8187177b0b1 ("drm: add helper for printing to log or seq_file") Cc: Rob Clark

[Intel-gfx] [PATCH 01/10] drm: Extract drm_dumb_buffers.c

Just code movement, doc cleanup will follow up later. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/Makefile| 3 +- drivers/gpu/drm/drm_crtc.c | 109 - drivers/gpu/drm/drm_crtc_internal.h | 18 ++---

[Intel-gfx] [PATCH 04/10] drm: Extract drm_drv.h

I want to move dumb buffer documentation into the right vfuncs, and for that I first need to be able to pull that into kerneldoc without having to clean up all of drmP.h. Also, header-splitting is nice. While at it shuffle all the function declarations for drm_drv.c into the right spots, and drop

[Intel-gfx] [PATCH 00/10] drm_crtc.[hc] cleanup and documenation

Hi all, Final bits, finally, leaving really only CRTC related code and structures in drm_crtc.[hc]. I guess next up is a bit of polish for atomic code, that has grown a lot and I think it'd be useful to split at least the helpers a bit. And a recent discussion with Rob Clark showed me that we've

[Intel-gfx] [PATCH 03/10] doc/dma-buf: Fix up include directives

Would be great if everony could add $ make DOCBOOKS="" htmldocs to their build scripts to catch these. 0day should also report them, not sure why it failed to spot this. Fixes: f54d1867005c ("dma-buf: Rename struct fence to dma_fence") Cc: Chris Wilson Cc: Gustavo

[Intel-gfx] [PATCH] dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence

The current code is subject to a race where we may try to acquire a reference on a stale fence: [13703.335118] WARNING: CPU: 1 PID: 14975 at ./include/linux/kref.h:46 i915_gem_object_wait+0x1a3/0x1c0 [13703.335184] Modules linked in: [13703.335202] CPU: 1 PID: 14975 Comm: gem_concurrent_ Not

Re: [Intel-gfx] [PATCH v3 08/14] drm/i915/scheduler: Execute requests in order of priorities

On 14/11/2016 11:41, Chris Wilson wrote: On Mon, Nov 14, 2016 at 11:15:52AM +, Tvrtko Ursulin wrote: On 14/11/2016 08:56, Chris Wilson wrote: +static void execlists_schedule(struct drm_i915_gem_request *request, int prio) +{ + struct intel_engine_cs *engine = NULL; + struct

Re: [Intel-gfx] [PATCH 0/4] Compact userptr object backing store allocation

Hi Andrew, On 11/11/2016 08:50, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Userptr backing store with SWIOTBL active is currently allocated in the same inefficient manner, with one sg entry per object page, as what the commit 871dfbd67d4e ("drm/i915: Allow

Re: [Intel-gfx] [PATCH v3 08/14] drm/i915/scheduler: Execute requests in order of priorities

On Mon, Nov 14, 2016 at 11:15:52AM +, Tvrtko Ursulin wrote: > On 14/11/2016 08:56, Chris Wilson wrote: > >+static void execlists_schedule(struct drm_i915_gem_request *request, int > >prio) > >+{ > >+struct intel_engine_cs *engine = NULL; > >+struct i915_dependency *dep, *p; > >+

Re: [Intel-gfx] [PATCH v3 12/14] drm/i915/scheduler: Support user-defined priorities

On 14/11/2016 08:57, Chris Wilson wrote: Use a priority stored in the context as the initial value when submitting a request. This allows us to change the default priority on a per-context basis, allowing different contexts to be favoured with GPU time at the expense of lower importance work.

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

On 14/11/2016 08:57, 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] [PATCH] drm/i915: Don't touch NULL sg on i915_gem_object_get_pages_gtt() error

On the DMA mapping error path, sg may be NULL (it has already been marked as the last scatterlist entry), and we should avoid dereferencing it again. Reported-by: Dan Carpenter Fixes: e227330223a7 ("drm/i915: avoid leaking DMA mappings") Signed-off-by: Chris Wilson

Re: [Intel-gfx] [bug report] drm/i915: Allow compaction upto SWIOTLB max segment size

On Mon, Nov 14, 2016 at 02:14:56PM +0300, Dan Carpenter wrote: > Hello Chris Wilson, > > The patch 871dfbd67d4e: "drm/i915: Allow compaction upto SWIOTLB max > segment size" from Oct 11, 2016, leads to the following static > checker warning: > > drivers/gpu/drm/i915/i915_gem.c:2357

Re: [Intel-gfx] [PATCH v3 09/14] drm/i915: Store the execution priority on the context

On 14/11/2016 08:56, Chris Wilson wrote: In order to support userspace defining different levels of importance to different contexts, and in particular the preferred order of execution, store a priority value on each context. By default, the kernel's context, which is used for idling and other

[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for GuC-based SLPC (rev6)

== Series Details == Series: Add support for GuC-based SLPC (rev6) URL : https://patchwork.freedesktop.org/series/2691/ State : success == Summary == Series 2691v6 Add support for GuC-based SLPC https://patchwork.freedesktop.org/api/1.0/series/2691/revisions/6/mbox/ fi-bdw-5557u

Re: [Intel-gfx] [PATCH v3 08/14] drm/i915/scheduler: Execute requests in order of priorities

On 14/11/2016 08:56, Chris Wilson wrote: Track the priority of each request and use it to determine the order in which we submit requests to the hardware via execlists. The priority of the request is determined by the user (eventually via the context) but may be overridden at any time by the

[Intel-gfx] [bug report] drm/i915: Allow compaction upto SWIOTLB max segment size

Hello Chris Wilson, The patch 871dfbd67d4e: "drm/i915: Allow compaction upto SWIOTLB max segment size" from Oct 11, 2016, leads to the following static checker warning: drivers/gpu/drm/i915/i915_gem.c:2357 i915_gem_object_get_pages_gtt() error: we previously assumed 'sg' could be

Re: [Intel-gfx] [PATCH v3 07/14] drm/i915/scheduler: Record all dependencies upon request construction

On 14/11/2016 08:56, Chris Wilson wrote: The scheduler needs to know the dependencies of each request for the lifetime of the request, as it may choose to reschedule the requests at any time and must ensure the dependency tree is not broken. This is in additional to using the fence to only

Re: [Intel-gfx] [PATCH v3 04/14] drm/i915: Defer transfer onto execution timeline to actual hw submission

On 14/11/2016 08:56, Chris Wilson wrote: Defer the transfer from the client's timeline onto the execution timeline from the point of readiness to the point of actual submission. For example, in execlists, a request is finally submitted to hardware when the hardware is ready, and only put onto

Re: [Intel-gfx] [PATCH v3 01/14] drm/i915: Give each sw_fence its own lockclass

On 14/11/2016 08:56, Chris Wilson wrote: Localise the static struct lock_class_key to the caller of i915_sw_fence_init() so that we create a lock_class instance for each unique sw_fence rather than all sw_fences sharing the same lock_class. This eliminate some lockdep false positive when using

Re: [Intel-gfx] [PATCH v11 3/4] drm/i915: Use new CRC debugfs API

On Thu, 06 Oct 2016, Tomeu Vizoso wrote: > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 23a6c7213eca..7412a05fa5d9 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c >

[Intel-gfx] [PATCH v5 22/22] drm/i915/slpc: Enable SLPC, where supported

From: Tom O'Rourke This patch makes SLPC enabled by default on platforms with hardware/firmware support. v1: Removing warning "enable_slpc < 0" as it is set to -1 with this patch now. This was caught by CI BAT. v2-v4: Rebase. v5: Sanitizing SLPC option based on

[Intel-gfx] [PATCH v1 1/1] tests/pm_slpc: Add test for GuC based SLPC

This tests whether SLPC in GuC is configured properly through shared data. It checks whether GTPERF is running in default state, post reset and post system suspend/resume. This test will be extended further based on enablement of other SLPC tasks. Signed-off-by: Sagar Arun Kamble

[Intel-gfx] [PATCH v5 19/22] drm/i915/slpc: Preserve min/max frequency softlimits on re-activation

v2: Removing checks for vma obj and kmap_atomic validity. (Chris) v3: Rebase. v4: Updated to make sure SLPC enable keeps min/max freq softlimits unchanged after initializing once. (Chris) v5: s/first_enable/i915_load_enable. Updating freq softlimits after checking that SLPC has

[Intel-gfx] [PATCH v5 14/22] drm/i915/slpc: Add parameter unset/set/get functions

From: Tom O'Rourke SLPC behavior can be changed through set of parameters. These parameters can be updated and queried from i915 though Host to GuC SLPC events. This patch add parameter values and events for setting/unsetting parameters. v1: Use host2guc_slpc update

[Intel-gfx] [PATCH v5 07/22] drm/i915/slpc: Enable SLPC in GuC if supported

From: Tom O'Rourke If slpc enabled, then add enable SLPC flag to guc control parameter during guc load. v1: Use intel_slpc_enabled() (Paulo) v2-v4: Rebase. v5: Changed intel_slpc_enabled() to i915.enable_slpc. (Sagar) Signed-off-by: Tom O'Rourke

[Intel-gfx] [PATCH v5 08/22] drm/i915/slpc: If using SLPC, do not set frequency

From: Tom O'Rourke When frequency requests are made by SLPC, host driver should not attempt to make frequency requests due to potential conflicts. Host-based turbo operations are already avoided when SLPC is used. This change covers other frequency requests such as from

[Intel-gfx] [PATCH v5 18/22] drm/i915/slpc: Only enable GTPERF task, Disable other tasks/parameters

v1: Updated tasks and frequency post reset. Added DFPS param update for MAX_FPS and FPS Stall. v2-v3: Rebase. v4: Updated with GuC firmware v9. v5: Rebase. Replaced H2G interrupts for parameter override with memory setup with required parameters. Signed-off-by: Sagar Arun Kamble

[Intel-gfx] [PATCH v5 20/22] drm/i915/slpc: Add SKL SLPC Support

From: Tom O'Rourke This patch adds has_slpc to skylake info. The SLPC interface has changed and could continue to change. Only GuC versions known to be compatible are supported here. On Skylake, GuC firmware v6 is supported. Other platforms and versions can be added

[Intel-gfx] [PATCH v5 02/22] drm/i915/slpc: Expose GuC functions for use with SLPC

From: Tom O'Rourke Expose host2guc_action for use by SLPC in intel_slpc.c. Expose functions to allocate and release objects used by GuC to be used for SLPC shared memory object. v1: Updated function names as they need to be made extern. (ChrisW) v2-v4: Rebase v5:

[Intel-gfx] [PATCH v5 13/22] drm/i915/slpc: Send shutdown event

From: Tom O'Rourke Send SLPC shutdown event during disable, suspend, and reset operations. Sending shutdown event while already shutdown is OK. v1: Return void instead of ignored error code (Paulo) Removed WARN_ON for checking msb of gtt address of shared gem

[Intel-gfx] [PATCH v5 21/22] drm/i915/slpc: Add Broxton SLPC support

From: Tom O'Rourke Adds has_slpc to broxton info and adds broxton firmware version check to sanitize_slpc_option. v1: Adjusted slpc version check for major version 8. Added message if version mismatch happens for easier debug. (Sagar) v2-v3: Rebase. v4: Commit

[Intel-gfx] [PATCH v5 04/22] drm/i915/slpc: Add enable_slpc module parameter

From: Tom O'Rourke i915.enable_slpc is used to override the default for slpc usage. The expected values are -1=auto, 0=disabled [default], 1=enabled. slpc_enable_sanitize() converts i915.enable_slpc to either 0 or 1. Interpretation of default value is based on

[Intel-gfx] [PATCH v5 15/22] drm/i915/slpc: Add support for min/max frequency control

From: Tom O'Rourke Update sysfs and debugfs functions to set SLPC parameters when setting max/min frequency. v1: Update for SLPC 2015.2.4 (params for both slice and unslice) Replace HAS_SLPC with intel_slpc_active() (Paulo) v2-v4: Rebase. v5: Removed typecasting

[Intel-gfx] [PATCH v5 06/22] drm/i915/slpc: Use intel_slpc_* functions if supported

From: Tom O'Rourke On platforms with SLPC support: call intel_slpc_*() functions from intel_*_gt_powersave() functions and GuC setup functions and do not use rps functions. intel_slpc_enable is tied to GuC setup. With SLPC, intel_enable_gt_powersave will only handle RC6

[Intel-gfx] [PATCH v5 17/22] drm/i915/slpc: Add i915_slpc_info to debugfs

From: Tom O'Rourke i915_slpc_info shows the contents of SLPC shared data parsed into text format. v1: Reformat slpc info (Radek) squashed query task state info in slpc info, kunmap before seq_print (Paulo) return void instead of ignored return value (Paulo)

[Intel-gfx] [PATCH v5 16/22] drm/i915/slpc: Add enable/disable controls for slpc tasks

From: Tom O'Rourke Adds debugfs hooks for enabling/disabling each slpc task. The enable/disable debugfs files are i915_slpc_gtperf, i915_slpc_balancer, and i915_slpc_dcc. Each of these can take the values: "default", "enabled", or "disabled" v1: update for SLPC

[Intel-gfx] [PATCH v5 11/22] drm/i915/slpc: Add slpc communication interfaces

From: Tom O'Rourke Communication with SLPC is via Host to GuC interrupt. This patch defines the data structure to be passed as input and received as output from SLPC. This patch also defines the events to be sent as input and status values output by GuC on processing SLPC

[Intel-gfx] [PATCH v5 03/22] drm/i915/slpc: Add has_slpc capability flag

From: Tom O'Rourke Add has_slpc capablity flag to indicate GuC firmware supports single loop power control (SLPC). SLPC is a replacement for some host-based power management features. v1: fix whitespace (Sagar) Reviewed-by: David Weinehall

[Intel-gfx] [PATCH v5 01/22] drm/i915/gen9: Separate RPS and RC6 handling

With GuC based SLPC, frequency control will be moved to GuC and Host will continue to control RC6 and Ring frequency setup. SLPC can be enabled in the GuC setup path and can happen in parallel in GuC with other i915 setup. Hence we can do away with deferred RPS enabling. This needs separate

[Intel-gfx] [PATCH v5 00/22] Add support for GuC-based SLPC

SLPC (Single Loop Power Controller) is a replacement for some host-based power management features. The SLPC implementation runs in firmware on GuC. This series has been tested with SKL and APL GuC firmware v9 (not released yet). Current GuC firmware's SLPC interfaces are updated in v9. The

[Intel-gfx] [PATCH v5 12/22] drm/i915/slpc: Send reset event and handle SLPC enabling

From: Tom O'Rourke Send host2guc SLPC reset event to GuC post GuC load. Post this, i915 can ascertain if SLPC has started running successfully through shared data. This check is done during intel_init_gt_powersave. This allows to get initial configuration setup by SLPC

[Intel-gfx] [PATCH v5 10/22] drm/i915/slpc: Update debugfs interfaces for frequency parameters

From: Tom O'Rourke When SLPC is controlling requested frequency, the rps.cur_freq value is not used to make the frequency request. Requested frequency from register RPNSWREQ has the value most recently requested by SLPC firmware. Adding new sysfs interface

[Intel-gfx] [PATCH v5 05/22] drm/i915/slpc: Sanitize GuC version

From: Tom O'Rourke The SLPC interface is dependent on GuC version. Only GuC versions known to be compatible are supported here. On SKL, BXT, KBL, GuC firmware v9 is supported. Other platforms and versions can be added here later. v1: Updated with modified

[Intel-gfx] [PATCH v5 09/22] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

From: Tom O'Rourke SLPC shared data is used to pass information to/from SLPC in GuC firmware. For Skylake, platform sku type and slice count are identified from device id and fuse values. Support for other platforms needs to be added. v1: Update for SLPC interface

[Intel-gfx] [i-g-t PATCH v6 4/4] igt/kms_busy.c: Use new igt_spin_batch

Cc: Chris Wilson Cc: Daniel Vetter Signed-off-by: Abdiel Janulgue --- tests/kms_busy.c | 75 +++- 1 file changed, 4 insertions(+), 71 deletions(-) diff --git

[Intel-gfx] (no subject)

On 11.11.2016 18:16, Daniel Vetter wrote: > On Fri, Nov 11, 2016 at 07:41:10PM +0200, Abdiel Janulgue wrote: >> A lot of igt testcases need some GPU workload to make sure a race >> window is big enough. Unfortunately having a fixed amount of >> workload leads to spurious test failures or overtly

[Intel-gfx] [i-g-t PATCH v6 3/4] igt/kms_flip: Use new igt_spin_batch

Cc: Chris Wilson Cc: Daniel Vetter Signed-off-by: Abdiel Janulgue --- tests/kms_flip.c | 185 ++- 1 file changed, 4 insertions(+), 181 deletions(-) diff --git

[Intel-gfx] [i-g-t PATCH v6 1/4] lib: add igt_dummyload

A lot of igt testcases need some GPU workload to make sure a race window is big enough. Unfortunately having a fixed amount of workload leads to spurious test failures or overtly long runtimes on some fast/slow platforms. This library contains functionality to submit GPU workloads that should

[Intel-gfx] [i-g-t PATCH v6 2/4] igt/gem_wait: Use new igt_spin_batch

Cc: Chris Wilson Cc: Daniel Vetter Signed-off-by: Abdiel Janulgue --- tests/gem_wait.c | 125 --- 1 file changed, 7 insertions(+), 118 deletions(-) diff --git

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Skip clflushes for all non-page backed objects

== Series Details == Series: series starting with [1/2] drm/i915: Skip clflushes for all non-page backed objects URL : https://patchwork.freedesktop.org/series/15255/ State : warning == Summary == Series 15255v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf: Replace reservation shared fence array with a compressed radix tree

== Series Details == Series: dma-buf: Replace reservation shared fence array with a compressed radix tree URL : https://patchwork.freedesktop.org/series/15252/ State : success == Summary == Series 15252v1 dma-buf: Replace reservation shared fence array with a compressed radix tree

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Prune the reservation shared fence array

== Series Details == Series: drm/i915: Prune the reservation shared fence array URL : https://patchwork.freedesktop.org/series/15254/ State : warning == Summary == Series 15254v1 drm/i915: Prune the reservation shared fence array

[Intel-gfx] [PATCH 10/12] tests/kms_atomic_transition: add out_fences tests

From: Gustavo Padovan Signed-off-by: Gustavo Padovan --- lib/igt_kms.c | 22 ++ tests/kms_atomic_transition.c | 30 -- 2 files changed, 50 insertions(+), 2

[Intel-gfx] [PATCH 12/12] tests/kms_atomic_transition: set out_fence for all crtcs

From: Gustavo Padovan Signed-off-by: Gustavo Padovan --- tests/kms_atomic_transition.c | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/tests/kms_atomic_transition.c

[Intel-gfx] [PATCH 08/12] tests/kms_atomic: stress possible fence settings

From: Gustavo Padovan Signed-off-by: Gustavo Padovan --- tests/kms_atomic.c | 124 + 1 file changed, 115 insertions(+), 9 deletions(-) diff --git a/tests/kms_atomic.c

Re: [Intel-gfx] [PATCH] dma-buf: Replace reservation shared fence array with a compressed radix tree

Hi Chris, Am 14.11.2016 um 09:31 schrieb Chris Wilson: The primary operation on the shared fence arrays is insertion and retrieval. Retrieval is reasonably fast, as we just copy the array, but insertion into the shared fence array is slow as we must iterate over all current fences to discard

[Intel-gfx] [PATCH 11/12] tests/kms_atomic_transition: add in_fences tests

From: Gustavo Padovan Signed-off-by: Gustavo Padovan --- tests/kms_atomic_transition.c | 92 ++- 1 file changed, 82 insertions(+), 10 deletions(-) diff --git

[Intel-gfx] [PATCH 09/12] tests/kms_atomic_transition: add fencing parameter to run_transition_tests

From: Gustavo Padovan Signed-off-by: Gustavo Padovan --- tests/kms_atomic_transition.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c

[Intel-gfx] [PATCH 06/12] lib/igt_kms: Add support for the IN_FENCE_FD property

From: Robert Foss Add support dor the IN_FENCE_FD property to enable setting in fences for atomic commits. Signed-off-by: Robert Foss --- lib/igt_kms.c | 20 lib/igt_kms.h | 5 + 2 files changed, 25 insertions(+)

[Intel-gfx] [PATCH 07/12] lib/igt_kms: Add support for the OUT_FENCE_PTR property

From: Gustavo Padovan Add support for the OUT_FENCE_PTR property to enable setting out fences for atomic commits. Signed-off-by: Gustavo Padovan --- lib/igt_kms.c | 20 +++- lib/igt_kms.h | 3 +++ 2 files

[Intel-gfx] [PATCH 05/12] tests/kms_atomic: use global atomic properties definitions

From: Gustavo Padovan Signed-off-by: Gustavo Padovan --- tests/kms_atomic.c | 123 - 1 file changed, 37 insertions(+), 86 deletions(-) diff --git a/tests/kms_atomic.c

[Intel-gfx] [PATCH 04/12] lib/igt_kms: export properties names

From: Gustavo Padovan Signed-off-by: Gustavo Padovan --- lib/igt_kms.c | 6 +++--- lib/igt_kms.h | 5 + 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index aa9fd16..8aaff5b

[Intel-gfx] [PATCH 00/12] kms tests for the DRM fences interfaces

From: Gustavo Padovan Hi, That is the first version of the igt tests for DRM fences[1]. The first four patches are just fix/improvements on the kms_atomic infrastructure. These patches depends on Robert Foss tests for sw_sync and a branch with those tests

[Intel-gfx] [PATCH 01/12] tests/kms_atomic_transition: use select + read instead of blocking read

From: Gustavo Padovan If the event never arrives we can timeout with select and end the test. Signed-off-by: Gustavo Padovan --- tests/kms_atomic_transition.c | 8 1 file changed, 8 insertions(+) diff --git

[Intel-gfx] [PATCH 03/12] lib/igt_kms: move igt_kms_get_alt_edid() to the right place

From: Gustavo Padovan Signed-off-by: Gustavo Padovan --- lib/igt_kms.c | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 989704e..aa9fd16

[Intel-gfx] [PATCH i-g-t 1/2] lib/drmtest: Fix igt_skip message

From: Gustavo Padovan Now other gpus are supported too. Signed-off-by: Gustavo Padovan --- lib/drmtest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/drmtest.c b/lib/drmtest.c index 884fe7c..9f3ac7f

[Intel-gfx] [PATCH i-g-t 2/2] lib/drmtest: add virtio_gpu support

From: Gustavo Padovan Support the virtio GPU on drmtest. Signed-off-by: Gustavo Padovan --- lib/drmtest.c | 9 + lib/drmtest.h | 1 + 2 files changed, 10 insertions(+) diff --git a/lib/drmtest.c b/lib/drmtest.c index

[Intel-gfx] [PATCH 02/12] tests/kms_atomic_transition: don't assume max pipes

From: Gustavo Padovan Signed-off-by: Gustavo Padovan --- tests/kms_atomic_transition.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c index

Re: [Intel-gfx] [PATCH 1/4] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages

On Fri, Nov 11, 2016 at 08:50:17AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Scatterlist entries have an unsigned int for the offset so > correct the sg_alloc_table_from_pages function accordingly. > > Since these are offsets withing a page, unsigned int

Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: Use __sg_alloc_table_from_pages for userptr allocations

On Fri, Nov 11, 2016 at 12:36:13PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > With the addition of __sg_alloc_table_from_pages we can control > the maximum coallescing size and eliminate a separate path for > allocating backing store here. > > Similar to

Re: [Intel-gfx] [PATCH v3 3/4] lib/scatterlist: Introduce and export __sg_alloc_table_from_pages

On Fri, Nov 11, 2016 at 02:17:44PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Drivers like i915 benefit from being able to control the maxium > size of the sg coallesced segment while building the scatter- > gather list. > > Introduce and export the

Re: [Intel-gfx] [PATCH] drm/i915/GuC: Combine the two kernel parameter into one

[corrected my email in cc] On 12/11/2016 02:21, Jeff McGee wrote: On Wed, Nov 09, 2016 at 11:11:07AM -0800, Anusha Srivatsa wrote: Replace i915.enable_guc_loading and i915.enable_guc_submission with a single parameter - i915.enable_guc. Where: -1 : Platform default (Only load GuC) 0 : Do not

Re: [Intel-gfx] [PATCH] dma-buf: Replace reservation shared fence array with a compressed radix tree

Hi Chris, [auto build test WARNING on drm/drm-next] [also build test WARNING on next-20161114] [cannot apply to v4.9-rc5] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/dma-buf

Re: [Intel-gfx] [PATCH v3 01/14] drm/i915: Give each sw_fence its own lockclass

On Mon, Nov 14, 2016 at 09:01:00AM +, Tvrtko Ursulin wrote: > > On 14/11/2016 08:56, Chris Wilson wrote: > >Localise the static struct lock_class_key to the caller of > >i915_sw_fence_init() so that we create a lock_class instance for each > >unique sw_fence rather than all sw_fences sharing

Re: [Intel-gfx] [PATCH v3 01/14] drm/i915: Give each sw_fence its own lockclass

On 14/11/2016 08:56, Chris Wilson wrote: Localise the static struct lock_class_key to the caller of i915_sw_fence_init() so that we create a lock_class instance for each unique sw_fence rather than all sw_fences sharing the same lock_class. This eliminate some lockdep false positive when using

[Intel-gfx] [PATCH v3 13/14] drm/i915: Enable userspace to opt-out of implicit fencing

Userspace is faced with a dilemma. The kernel requires implicit fencing to manage resource usage (we always must wait for the GPU to finish before releasing its PTE) and for third parties. However, userspace may wish to avoid this serialisation if it is either using explicit fencing between

[Intel-gfx] [PATCH v3 07/14] drm/i915/scheduler: Record all dependencies upon request construction

The scheduler needs to know the dependencies of each request for the lifetime of the request, as it may choose to reschedule the requests at any time and must ensure the dependency tree is not broken. This is in additional to using the fence to only allow execution after all dependencies have been

[Intel-gfx] [PATCH v3 02/14] drm/i915: Create distinct lockclasses for execution vs user timelines

In order to simplify the lockdep annotation, as they become more complex in the future with deferred execution and multiple paths through the same functions, create a separate lockclass for the user timeline and the hardware execution timeline. We should only ever be locking the user timeline and

[Intel-gfx] [PATCH v3 01/14] drm/i915: Give each sw_fence its own lockclass

Localise the static struct lock_class_key to the caller of i915_sw_fence_init() so that we create a lock_class instance for each unique sw_fence rather than all sw_fences sharing the same lock_class. This eliminate some lockdep false positive when using fences from within fence callbacks.

<    1   2   3   >