[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences

== Series Details == Series: series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences URL : https://patchwork.freedesktop.org/series/40927/ State : failure == Summary == Series 40927v1 series starting with [01/17] drm/i915/execlists: Track begin/end

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add support for GuC-based SLPC (rev12)

== Series Details == Series: Add support for GuC-based SLPC (rev12) URL : https://patchwork.freedesktop.org/series/2691/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/guc/slpc: Add SLPC control to enable_guc modparam Okay! Commit: drm/i915/guc/slpc: Disable host

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences

== Series Details == Series: series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences URL : https://patchwork.freedesktop.org/series/40927/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0a86b9f594fb drm/i915/execlists: Track begin/end

[Intel-gfx] [PATCH v12 10/17] drm/i915/guc/slpc: Add parameter set/unset/get, task control/status functions

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 adds parameter update events for setting/unsetting/getting params. Setting parameter leads to overridding of default parameter value. Unset leads

[Intel-gfx] [PATCH v12 05/17] drm/i915/guc/slpc: Add SLPC communication interfaces

Communication with SLPC is via Host to GuC interrupt through shared data and parameters. This patch defines the structure of shared data, parameters, 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

[Intel-gfx] [PATCH v12 03/17] drm/i915/guc/slpc: Lay out SLPC init/enable/disable/fini helpers

SLPC operates based on parameters setup in shared data between i915 and GuC SLPC. This is to be created/initialized in intel_guc_slpc_init. From there onwards i915 can control the SLPC operations by enabling, disabling complete SLPC or changing SLPC parameters. During cleanup, SLPC shared data has

[Intel-gfx] [PATCH v12 07/17] drm/i915/guc/slpc: Send RESET event to restart/enable SLPC tasks

Host to GuC actions for SLPC receive additional data as output through scratch registers currently. intel_guc_send_and_receive handles this. We need to define SLPC specific Host to GuC send action (slpc_send) as wrapper on top of it to process the SLPC status that is received in SOFT_SCRATCH(1).

[Intel-gfx] [PATCH v12 02/17] drm/i915/guc/slpc: Disable host RPS

On platforms with GuC SLPC enabled, we need to ensure Host RPS functions don't update HW RPS state that will be controlled by GuC SLPC then. Host RPS functions are now gated by either USES_GUC_SLPC() or rps->enabled checks. If SLPC is enabled following functions will be bypassed 1. gpu_ips_init

[Intel-gfx] [PATCH v12 06/17] drm/i915/guc/slpc: Allocate/initialize/release SLPC shared data

Populate SLPC shared data with required default values for slice count, power source/plan, IA perf MSRs. v1: Update for SLPC interface version 2015.2.4. intel_slpc_active() returns 1 if slpc initialized (Paulo) change default host_os to "Windows" Spelling fixes (Sagar and Nick Hoath).

[Intel-gfx] [PATCH v12 04/17] drm/i915/guc/slpc: Enable SLPC in GuC load control params

From: Tom O'Rourke If SLPC is to enabled, then set GUC_CTL_ENABLE_SLPC flag in GuC control param GUC_CTL_FEATURE word during GuC load. This is required for early SLPC init in GuC init path. SLPC gets enabled fully on sending this flag during GuC load and on doing SLPC

[Intel-gfx] [PATCH v12 00/17] 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 GuC firmware. This series has been tested with SKL/APL/KBL GuC firmware v9 and v10. The graphics power management features in SLPC are called GTPERF, BALANCER and

[Intel-gfx] [PATCH v12 08/17] drm/i915/guc/slpc: Send SHUTDOWN event to stop SLPC tasks

From: Tom O'Rourke Send SLPC shutdown event during uc_fini_hw or prior to enabling SLPC done while communicating updated parameters in shared data. v1: Return void instead of ignored error code (Paulo). Removed WARN_ON for checking msb of gtt address of shared gem

[Intel-gfx] [PATCH v12 01/17] drm/i915/guc/slpc: Add SLPC control to enable_guc modparam

From: Tom O'Rourke GuC is currently being used for submission and HuC authentication. Choices can be configured through enable_guc modparam. GuC SLPC is GT Power and Performance management feature in GuC. Add another option to enable_guc modparam to control SLPC. v1: Add

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences

== Series Details == Series: series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences URL : https://patchwork.freedesktop.org/series/40927/ State : success == Summary == Series 40927v1 series starting with [01/17] drm/i915/execlists: Track begin/end

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev4)

== Series Details == Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev4) URL : https://patchwork.freedesktop.org/series/36068/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5ab2dbdddfa3 drm/i915: Introduce CRTC output format -:86: CHECK:PARENTHESIS_ALIGNMENT: Alignment

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences

== Series Details == Series: series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences URL : https://patchwork.freedesktop.org/series/40927/ State : warning == Summary == $ dim checkpatch origin/drm-tip d71000599823 drm/i915/execlists: Track begin/end

Re: [Intel-gfx] [PATCH] drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

> + Zhi and Zhenyu > > Quoting Xiong Zhang (2018-03-29 13:58:41) > > Four drm_mm_node are used to reserve guest ggtt space, but some of > > them may aren't initialized and used in intel_vgt_balloon(), so these > > unused drm_mm_node couldn't be removed through > drm_mm_remove_node(). > > I'm not

[Intel-gfx] [PATCH v12 12/17] drm/i915/guc/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_guc_slpc_gtperf, i915_guc_slpc_balancer, and i915_guc_slpc_dcc. Each of these can take the values: "default", "enabled", or "disabled" v1: update for

[Intel-gfx] [PATCH v12 14/17] drm/i915/guc/slpc: Add debugfs support to read/write/revert the parameters

Add support to set/read parameters and unset the parameters which will revert them to default SLPC internal values. Explicit SLPC reset is needed on setting/unsetting some of the parameters. This patch adds two debugfs interfaces: 1. i915_guc_slpc_params: List of all parameters that Host can

[Intel-gfx] [PATCH v12 11/17] drm/i915/guc/slpc: Add support for sysfs min/max frequency control

Update sysfs functions to set SLPC parameters when setting max/min user frequency limits. 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 the frequency values to u32. (Chris). Changed

[Intel-gfx] [PATCH v12 16/17] drm/i915/guc/slpc: Add SLPC banner to RPS debugfs interfaces

When SLPC is controlling frequency requests, RPS state related to autotuning is no longer valid. Make user aware through banner upfront. Value read from register RPNSWREQ likely has the frequency requested last by GuC SLPC. v1: Replace HAS_SLPC with intel_slpc_active (Paulo) Avoid magic

[Intel-gfx] [PATCH v12 09/17] drm/i915/guc/slpc: Reset SLPC on engine reset with flag TDR_OCCURRED

On engine reset, SLPC needs to be notified for it to clear metrics/stats. This is done by sending GUC_SLPC_EVENT_RESET with a flag GUC_SLPC_RESET_FLAG_TDR_OCCURRED. v2: Full GPU reset in i915 triggers reload of GuC and SLPC reset happens along that path. Hence only handling engine reset.

[Intel-gfx] [PATCH v12 13/17] drm/i915/debugfs: Create generic string tokenize function and update CRC control parsing

Input string parsing used in CRC control parameter parsing is generic and can be reused for other debugfs interfaces. We plan to use this in the next patch for SLPC debugfs control. Hence name it as buffer_tokenize instead of tying to display_crc. Also fix the function desciption for CRC control

[Intel-gfx] [PATCH v12 15/17] drm/i915/guc/slpc: Add i915_guc_slpc_info to debugfs

From: Tom O'Rourke i915_guc_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 v12 17/17] HAX: drm/i915/guc: Enable GuC

Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 2484925..dd2de06 100644 ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add support for GuC-based SLPC (rev12)

== Series Details == Series: Add support for GuC-based SLPC (rev12) URL : https://patchwork.freedesktop.org/series/2691/ State : failure == Summary == Series 2691v12 Add support for GuC-based SLPC https://patchwork.freedesktop.org/api/1.0/series/2691/revisions/12/mbox/ Warning: Kernel 32bit

Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.

I think the adoption is not a problem here. If driver can query that patch is active on the specific setup, new capabilities will be always reported to the user. -Original Message- Quoting Dunajski, Bartosz (2018-03-26 12:46:13) > Here is pull request with patch usage: >

[Intel-gfx] [PATCH 16/17] drm/i915: Use a preemption timeout to enforce interactivity

Use a liberal timeout of 20ms to ensure that the rendering for an interactive pageflip is started in a timely fashion, and that user interaction is not blocked by GPU, or CPU, hogs. This is at the cost of resetting whoever was blocking the preemption, likely leading to that context/process being

[Intel-gfx] [PATCH 10/17] drm/i915: Stop parking the signaler around reset

We cannot call kthread_park() from softirq context, so let's avoid it entirely during the reset. We wanted to suspend the signaler so that it would not mark a request as complete at the same time as we marked it as being in error. Instead of parking the signaling, stop the engine from advancing so

[Intel-gfx] [PATCH 12/17] drm/i915: Allow init_breadcrumbs to be used from irq context

In order to support engine reset from irq (timer) context, we need to be able to re-initialise the breadcrumbs. So we need to promote the plain spin_lock_irq to a safe spin_lock_irqsave. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 5 +++--

[Intel-gfx] [PATCH 08/17] drm/i915/breadcrumbs: Keep the fake irq armed across reset

Instead of synchronously cancelling the timer and re-enabling it inside the reset callbacks, keep the timer enabled and let it die on its next wakeup if no longer required. This allows intel_engine_reset_breadcrumbs() to be used from an atomic (timer/softirq) context such as required for resetting

[Intel-gfx] [PATCH 07/17] drm/i915/selftests: Add basic sanitychecks for execlists

Before adding a new feature to execlists submission, we should endeavour to cover the baseline behaviour with selftests. So start the ball rolling. Signed-off-by: Chris Wilson Cc: Michał Winiarski CC: Michel Thierry

[Intel-gfx] [PATCH 14/17] drm/i915/execlists: Try preempt-reset from softirq context

When circumstances allow, trying resetting the engine directly from the preemption timeout handler. As this is softirq context, we have to be careful both not to sleep and not to spin on anything we may be interrupting (e.g. the submission tasklet). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 02/17] drm/i915/execlists: Set queue priority from secondary port

We can refine our current execlists->queue_priority if we inspect ELSP[1] rather than the head of the unsubmitted queue. Currently, we use the unsubmitted queue and say that if a subsequent request is more than important than the current queue, we will rerun the submission tasklet to evaluate the

[Intel-gfx] [PATCH 04/17] drm/i915: Move engine reset prepare/finish to backends

In preparation to more carefully handling incomplete preemption during reset by execlists, we move the existing code wholesale to the backends under a couple of new reset vfuncs. Signed-off-by: Chris Wilson Cc: Michał Winiarski CC: Michel

[Intel-gfx] [PATCH 06/17] drm/i915/execlists: Flush pending preemption events during reset

Catch up with the inflight CSB events, after disabling the tasklet before deciding which request was truly guilty of hanging the GPU. v2: Restore checking of use_csb_mmio on every loop, don't forget old vgpu. Signed-off-by: Chris Wilson Cc: Michał Winiarski

[Intel-gfx] [PATCH 09/17] drm/i915: Combine tasklet_kill and tasklet_disable

Ideally, we want to atomically flush and disable the tasklet before resetting the GPU. At present, we rely on being the only part to touch our tasklet and serialisation of the reset process to ensure that we can suspend the tasklet from the mix of reset/wedge pathways. In this patch, we move the

[Intel-gfx] [PATCH 05/17] drm/i915: Split execlists/guc reset prepartions

In the next patch, we will make the execlists reset prepare callback take into account preemption by flushing the context-switch handler. This is not applicable to the GuC submission backend, so split the two into their own backend callbacks. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PULL] more gvt-next-fixes for 4.17

On 2018.03.28 16:26:17 +0800, Zhenyu Wang wrote: > > Hi, Joonas > > Here's refreshed pull for 4.17 without that revert patch which > also include new fixes for ggtt dma unmap and virtual display. > Joonas, pls ignore this one, smoke test pass but seems new issue found in full test. I'll send

Re: [Intel-gfx] [PATCH] drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest

On 2018.03.30 07:01:02 +, Zhang, Xiong Y wrote: > > + Zhi and Zhenyu > > > > Quoting Xiong Zhang (2018-03-29 13:58:41) > > > Four drm_mm_node are used to reserve guest ggtt space, but some of > > > them may aren't initialized and used in intel_vgt_balloon(), so these > > > unused drm_mm_node

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev4)

== Series Details == Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev4) URL : https://patchwork.freedesktop.org/series/36068/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Introduce CRTC output format Okay! Commit: drm/i915: Add CRTC output format YCBCR

[Intel-gfx] ✗ Fi.CI.BAT: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev4)

== Series Details == Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev4) URL : https://patchwork.freedesktop.org/series/36068/ State : warning == Summary == Series 36068v4 YCBCR 4:2:0/4:4:4 output support for LSPCON

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add support for GuC-based SLPC (rev12)

== Series Details == Series: Add support for GuC-based SLPC (rev12) URL : https://patchwork.freedesktop.org/series/2691/ State : warning == Summary == $ dim checkpatch origin/drm-tip d53e35c3815d drm/i915/guc/slpc: Add SLPC control to enable_guc modparam 6cf8c81b2bca drm/i915/guc/slpc:

[Intel-gfx] [PATCH 13/17] drm/i915/execlists: Force preemption via reset on timeout

Install a timer when trying to preempt on behalf of an important context such that if the active context does not honour the preemption request within the desired timeout, then we reset the GPU to allow the important context to run. v2: Install the timer on scheduling the preempt request; long

[Intel-gfx] Reset from within timeout for preemption Qos

Fleshed out the reset from within the timer context (hardirq) to the point where it at least passes selftests... Not that CI even likes the sanitycheck at the moment. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 01/17] drm/i915/execlists: Track begin/end of execlists submission sequences

We would like to start doing some bookkeeping at the beginning, between contexts and at the end of execlists submission. We already mark the beginning and end using EXECLISTS_ACTIVE_USER, to provide an indication when the HW is idle. This give us a pair of sequence points we can then expand on for

[Intel-gfx] [PATCH 15/17] drm/i915/preemption: Select timeout when scheduling

The choice of preemption timeout is determined by the context from which we trigger the preemption, as such allow the caller to specify the desired timeout. Effectively the other choice would be to use the shortest timeout along the dependency chain. However, given that we would have already

[Intel-gfx] [PATCH 11/17] drm/i915: Be irqsafe inside reset

As we want to be able to call i915_reset_engine and co from a softirq or timer context, we need to be irqsafe at all timers. So we have to forgo the simple spin_lock_irq for the full spin_lock_irqsave. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 6

[Intel-gfx] [PATCH 17/17] drm/i915: Allow user control over preempt timeout on their important context

EGL_NV_realtime_priority? Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c| 22 drivers/gpu/drm/i915/i915_gem_context.h| 13 + drivers/gpu/drm/i915/i915_request.c| 8 ++- drivers/gpu/drm/i915/intel_lrc.c |

[Intel-gfx] [PATCH 03/17] drm/i915/execlists: Refactor out complete_preempt_context()

As a complement to inject_preempt_context(), follow up with the function to handle its completion. This will be useful should we wish to extend the duties of the preempt-context for execlists. v2: And do the same for the guc. Signed-off-by: Chris Wilson Cc: Jeff McGee

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Avoid repeatedly harming the same innocent context

== Series Details == Series: drm/i915/selftests: Avoid repeatedly harming the same innocent context URL : https://patchwork.freedesktop.org/series/40941/ State : warning == Summary == $ dim checkpatch origin/drm-tip 477c0fa0c0b5 drm/i915/selftests: Avoid repeatedly harming the same innocent

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

== Series Details == Series: drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers URL : https://patchwork.freedesktop.org/series/40929/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-dpms-vs-vblank-race: fail

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Consistent seqno reporting in GEM_TRACE

: https://github.com/0day-ci/linux/commits/Tvrtko-Ursulin/drm-i915-execlists-Consistent-seqno-reporting-in-GEM_TRACE/20180330-120802 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-randconfig-x0-03302126 (attached as .config) compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010

[Intel-gfx] [PATCH 01/18] drm/i915/selftests: Avoid repeatedly harming the same innocent context

We don't handle resetting the kernel context very well, or presumably any context executing its breadcrumb commands in the ring as opposed to the batchbuffer and flush. If we trigger a device reset twice in quick succession while the kernel context is executing, we may end up skipping the

[Intel-gfx] Preemption reset from timer; CI now 110% happier

Fixed up the couple of bugs in the selftests that CI was tripping over, or so I hope... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

On Fri, 30 Mar 2018 15:07:53 +0100 Chris Wilson wrote: > Sure, I was mainly floating the idea of trying to pick sensible > defaults. Unstable clocks are quite rare nowadays, the ones we have in > the lab are a pair of Core2 Duo. I still have a box too ;-) I'm not so

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences

== Series Details == Series: series starting with [01/17] drm/i915/execlists: Track begin/end of execlists submission sequences URL : https://patchwork.freedesktop.org/series/40927/ State : failure == Summary == Possible new issues: Test drv_selftest: Subgroup live_hangcheck:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

== Series Details == Series: drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers URL : https://patchwork.freedesktop.org/series/40929/ State : success == Summary == Series 40929v1 drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Re: [Intel-gfx] [PATCH v12 05/17] drm/i915/guc/slpc: Add SLPC communication interfaces

On Fri, 30 Mar 2018 10:31:50 +0200, Sagar Arun Kamble wrote: Communication with SLPC is via Host to GuC interrupt through shared data and parameters. This patch defines the structure of shared data, parameters, data structure to be passed as input and received as

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Avoid repeatedly harming the same innocent context

== Series Details == Series: drm/i915/selftests: Avoid repeatedly harming the same innocent context URL : https://patchwork.freedesktop.org/series/40941/ State : failure == Summary == Possible new issues: Test kms_cursor_legacy: Subgroup cursor-vs-flip-atomic-transitions:

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] trace: Default to using trace_global_clock if sched_clock is unstable

== Series Details == Series: series starting with [v2,1/2] trace: Default to using trace_global_clock if sched_clock is unstable URL : https://patchwork.freedesktop.org/series/40952/ State : failure == Summary == Series 40952v1 series starting with [v2,1/2] trace: Default to using

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Quoting Hans de Goede (2018-03-30 13:37:40) > Hi, > > On 30-03-18 14:30, Chris Wilson wrote: > > Quoting Hans de Goede (2018-03-30 13:27:15) > >> Before this commit the WaSkipStolenMemoryFirstPage workaround code was > >> skipping the first 4k by passing 4096 as start of the address range passed

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Avoid repeatedly harming the same innocent context

== Series Details == Series: drm/i915/selftests: Avoid repeatedly harming the same innocent context URL : https://patchwork.freedesktop.org/series/40941/ State : success == Summary == Series 40941v1 drm/i915/selftests: Avoid repeatedly harming the same innocent context

Re: [Intel-gfx] [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

Quoting Steven Rostedt (2018-03-30 14:48:45) > On Thu, 29 Mar 2018 23:25:57 +0100 > Chris Wilson wrote: > > > Across suspend, we may see a very large drift in timestamps if the sched > > clock is unstable, prompting the global trace's ringbuffer code to warn > > and

Re: [Intel-gfx] [PATCH v1] drm/i915/gen11: Preempt-to-idle support in execlists.

On 2018-03-29 00:28, Chris Wilson wrote: Quoting Lis, Tomasz (2018-03-28 17:06:58) On 2018-03-28 01:27, Chris Wilson wrote: Quoting Tomasz Lis (2018-03-27 16:17:59) The patch adds support of preempt-to-idle requesting by setting a proper bit within Execlist Control Register, and receiving

[Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Before this commit the WaSkipStolenMemoryFirstPage workaround code was skipping the first 4k by passing 4096 as start of the address range passed to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and reserve the firmware framebuffer so that we can inherit it would always fail,

[Intel-gfx] [PATCH] drm/i915/selftests: Avoid repeatedly harming the same innocent context

We don't handle resetting the kernel context very well, or presumably any context executing its breadcrumb commands in the ring as opposed to the batchbuffer and flush. If we trigger a device reset twice in quick succession while the kernel context is executing, we may end up skipping the

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Hi, On 30-03-18 14:44, Chris Wilson wrote: Quoting Hans de Goede (2018-03-30 13:37:40) Hi, On 30-03-18 14:30, Chris Wilson wrote: Quoting Hans de Goede (2018-03-30 13:27:15) Before this commit the WaSkipStolenMemoryFirstPage workaround code was skipping the first 4k by passing 4096 as start

Re: [Intel-gfx] [PATCH v12 01/17] drm/i915/guc/slpc: Add SLPC control to enable_guc modparam

Thanks for the review. Will update with all suggestions in the next rev. On 3/30/2018 6:07 PM, Michal Wajdeczko wrote: On Fri, 30 Mar 2018 10:31:46 +0200, Sagar Arun Kamble wrote: From: Tom O'Rourke GuC is currently being used for

Re: [Intel-gfx] [PATCH v12 01/17] drm/i915/guc/slpc: Add SLPC control to enable_guc modparam

On Fri, 30 Mar 2018 10:31:46 +0200, Sagar Arun Kamble wrote: From: Tom O'Rourke GuC is currently being used for submission and HuC authentication. Choices can be configured through enable_guc modparam. GuC SLPC is GT Power and Performance

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Hi, On 30-03-18 14:30, Chris Wilson wrote: Quoting Hans de Goede (2018-03-30 13:27:15) Before this commit the WaSkipStolenMemoryFirstPage workaround code was skipping the first 4k by passing 4096 as start of the address range passed to drm_mm_init(). This means that calling

Re: [Intel-gfx] [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

On Thu, 29 Mar 2018 23:25:57 +0100 Chris Wilson wrote: > Across suspend, we may see a very large drift in timestamps if the sched > clock is unstable, prompting the global trace's ringbuffer code to warn > and suggest switching to the global clock. Preempt this request

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Hi, On 30-03-18 15:25, Hans de Goede wrote: Hi, On 30-03-18 14:44, Chris Wilson wrote: Quoting Hans de Goede (2018-03-30 13:37:40) Hi, On 30-03-18 14:30, Chris Wilson wrote: Quoting Hans de Goede (2018-03-30 13:27:15) Before this commit the WaSkipStolenMemoryFirstPage workaround code was

Re: [Intel-gfx] [PATCH 00/24] drm_framebuffer boilerplate removal

On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote: > Hi, > I've been working on a getfb2[0] ioctl, which amongst other things > supports multi-planar framebuffers as well as modifiers. getfb > currently calls the framebuffer's handle_create hook, which doesn't > support

[Intel-gfx] [PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable

Across suspend, we may see a very large drift in timestamps if the sched clock is unstable, prompting the global trace's ringbuffer code to warn and suggest switching to the global clock. Preempt this request by detecting when the sched clock is unstable (determined during late_initcall) and

[Intel-gfx] [PATCH v2 2/2] trace: Mention trace_clock=global when warning about unstable clocks

Mention the alternative of adding trace_clock=global to the kernel command line when we detect that we've used an unstable clock across a suspend/resume cycle. Signed-off-by: Chris Wilson Cc: Steven Rostedt --- kernel/trace/ring_buffer.c | 3 ++-

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] trace: Default to using trace_global_clock if sched_clock is unstable

== Series Details == Series: series starting with [v2,1/2] trace: Default to using trace_global_clock if sched_clock is unstable URL : https://patchwork.freedesktop.org/series/40952/ State : warning == Summary == $ dim checkpatch origin/drm-tip 935d891f5719 trace: Default to using

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Quoting Hans de Goede (2018-03-30 13:27:15) > Before this commit the WaSkipStolenMemoryFirstPage workaround code was > skipping the first 4k by passing 4096 as start of the address range passed > to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and > reserve the firmware

[Intel-gfx] [PATCH 00/24] drm_framebuffer boilerplate removal

Hi, I've been working on a getfb2[0] ioctl, which amongst other things supports multi-planar framebuffers as well as modifiers. getfb currently calls the framebuffer's handle_create hook, which doesn't support multiple planes. Thanks to Noralf's recent work, drivers can just store GEM objects

[Intel-gfx] [PATCH 08/18] drm/i915/selftests: Add basic sanitychecks for execlists

Before adding a new feature to execlists submission, we should endeavour to cover the baseline behaviour with selftests. So start the ball rolling. Signed-off-by: Chris Wilson Cc: Michał Winiarski CC: Michel Thierry

[Intel-gfx] [PATCH 07/18] drm/i915/execlists: Flush pending preemption events during reset

Catch up with the inflight CSB events, after disabling the tasklet before deciding which request was truly guilty of hanging the GPU. v2: Restore checking of use_csb_mmio on every loop, don't forget old vgpu. Signed-off-by: Chris Wilson Cc: Michał Winiarski

[Intel-gfx] [PATCH 16/18] drm/i915/preemption: Select timeout when scheduling

The choice of preemption timeout is determined by the context from which we trigger the preemption, as such allow the caller to specify the desired timeout. Effectively the other choice would be to use the shortest timeout along the dependency chain. However, given that we would have already

[Intel-gfx] [PATCH 03/18] drm/i915/execlists: Set queue priority from secondary port

We can refine our current execlists->queue_priority if we inspect ELSP[1] rather than the head of the unsubmitted queue. Currently, we use the unsubmitted queue and say that if a subsequent request is more than important than the current queue, we will rerun the submission tasklet to evaluate the

[Intel-gfx] [PATCH 18/18] drm/i915: Allow user control over preempt timeout on their important context

EGL_NV_realtime_priority? Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c| 22 drivers/gpu/drm/i915/i915_gem_context.h| 13 + drivers/gpu/drm/i915/i915_request.c| 8 ++- drivers/gpu/drm/i915/intel_lrc.c |

[Intel-gfx] [PATCH 17/18] drm/i915: Use a preemption timeout to enforce interactivity

Use a liberal timeout of 20ms to ensure that the rendering for an interactive pageflip is started in a timely fashion, and that user interaction is not blocked by GPU, or CPU, hogs. This is at the cost of resetting whoever was blocking the preemption, likely leading to that context/process being

[Intel-gfx] [PATCH 15/18] drm/i915/execlists: Try preempt-reset from softirq context

When circumstances allow, trying resetting the engine directly from the preemption timeout handler. As this is softirq context, we have to be careful both not to sleep and not to spin on anything we may be interrupting (e.g. the submission tasklet). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 09/18] drm/i915/breadcrumbs: Keep the fake irq armed across reset

Instead of synchronously cancelling the timer and re-enabling it inside the reset callbacks, keep the timer enabled and let it die on its next wakeup if no longer required. This allows intel_engine_reset_breadcrumbs() to be used from an atomic (timer/softirq) context such as required for resetting

[Intel-gfx] [PATCH 05/18] drm/i915: Move engine reset prepare/finish to backends

In preparation to more carefully handling incomplete preemption during reset by execlists, we move the existing code wholesale to the backends under a couple of new reset vfuncs. Signed-off-by: Chris Wilson Cc: Michał Winiarski CC: Michel

[Intel-gfx] [PATCH 10/18] drm/i915: Combine tasklet_kill and tasklet_disable

Ideally, we want to atomically flush and disable the tasklet before resetting the GPU. At present, we rely on being the only part to touch our tasklet and serialisation of the reset process to ensure that we can suspend the tasklet from the mix of reset/wedge pathways. In this patch, we move the

[Intel-gfx] [PATCH 11/18] drm/i915: Stop parking the signaler around reset

We cannot call kthread_park() from softirq context, so let's avoid it entirely during the reset. We wanted to suspend the signaler so that it would not mark a request as complete at the same time as we marked it as being in error. Instead of parking the signaling, stop the engine from advancing so

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/18] drm/i915/selftests: Avoid repeatedly harming the same innocent context

== Series Details == Series: series starting with [01/18] drm/i915/selftests: Avoid repeatedly harming the same innocent context URL : https://patchwork.freedesktop.org/series/40961/ State : warning == Summary == $ dim checkpatch origin/drm-tip 33a1831a25b2 drm/i915/selftests: Avoid

Re: [Intel-gfx] [PATCH v3 05/10] drm/i915/psr/cnl: Enable Y-coordinate support in source

On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote: > For Geminilake and Cannonlake+ the Y-coordinate support must be > enabled in PSR2_CTL too. > > Spec: 7713 and 7720 > > Cc: Dhinakaran Pandiyan > Reviewed-by: Rodrigo Vivi

Re: [Intel-gfx] [PATCH v1] drm/i915/gen11: Preempt-to-idle support in execlists.

On 27/03/18 16:27, Chris Wilson wrote: Quoting Tomasz Lis (2018-03-27 16:17:59) The patch adds support of preempt-to-idle requesting by setting a proper bit within Execlist Control Register, and receiving preemption result from Context Status Buffer. Preemption in previous gens required a

Re: [Intel-gfx] [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

Francisco Jerez writes: > This series attempts to solve an energy efficiency problem of the > current active-mode non-HWP governor of the intel_pstate driver used > for the most part on low-power platforms. Under heavy IO load the > current controller tends to increase

Re: [Intel-gfx] [PATCH] drm/i915: Promote .format_mod_supported() to the lead role

Ville Syrjala writes: > From: Ville Syrjälä > > Up to now we've used the plane's modifier list as the primary > source of information for which modifiers are supported by a > given plane. In order to allow auxiliary metadata to be

[Intel-gfx] [PATCH 06/18] drm/i915: Split execlists/guc reset prepartions

In the next patch, we will make the execlists reset prepare callback take into account preemption by flushing the context-switch handler. This is not applicable to the GuC submission backend, so split the two into their own backend callbacks. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 13/18] drm/i915: Allow init_breadcrumbs to be used from irq context

In order to support engine reset from irq (timer) context, we need to be able to re-initialise the breadcrumbs. So we need to promote the plain spin_lock_irq to a safe spin_lock_irqsave. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 5 +++--

[Intel-gfx] [PATCH 12/18] drm/i915: Be irqsafe inside reset

As we want to be able to call i915_reset_engine and co from a softirq or timer context, we need to be irqsafe at all timers. So we have to forgo the simple spin_lock_irq for the full spin_lock_irqsave. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 6

[Intel-gfx] [PATCH 02/18] drm/i915/execlists: Track begin/end of execlists submission sequences

We would like to start doing some bookkeeping at the beginning, between contexts and at the end of execlists submission. We already mark the beginning and end using EXECLISTS_ACTIVE_USER, to provide an indication when the HW is idle. This give us a pair of sequence points we can then expand on for

[Intel-gfx] [PATCH 04/18] drm/i915/execlists: Refactor out complete_preempt_context()

As a complement to inject_preempt_context(), follow up with the function to handle its completion. This will be useful should we wish to extend the duties of the preempt-context for execlists. v2: And do the same for the guc. Signed-off-by: Chris Wilson Cc: Jeff McGee

  1   2   >