Re: [Intel-gfx] [PATCH 7/7] drm/i915: Engine queues query

On 19/03/18 18:16, Tvrtko Ursulin wrote: From: Tvrtko Ursulin As well as exposing active requests on engines via PMU, we can also export the current raw values (as tracked by i915 command submission) via a dedicated query. This is to satisfy customers who have

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP

On Fri, 2018-03-30 at 16:46 -0700, Pandiyan, Dhinakaran wrote: > On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote: > > This was my bad, spec says that the name of this bit is > > 'Y-coordinate valid' but the values for it is: > > 0: Include Y-coordinate valid eDP1.4a > > 1: Do not

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP

On Fri, 2018-03-30 at 14:15 -0700, José Roberto de Souza wrote: > This was my bad, spec says that the name of this bit is > 'Y-coordinate valid' but the values for it is: > 0: Include Y-coordinate valid eDP1.4a > 1: Do not include Y-coordinate valid eDP 1.4 > So renaming the bit and not setting

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use full serialisation around engine->irq_posted

Quoting Chris Wilson (2018-03-22 07:35:32) > Using engine->irq_posted for execlists, we are not always serialised by > the tasklet as we supposed. On the reset paths, the tasklet is disabled > and ignored. Instead, we manipulate the engine->irq_posted directly to > account for the reset, but if an

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function

== Series Details == Series: series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function URL : https://patchwork.freedesktop.org/series/40978/ State : warning == Summary == Series 40978v1 series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON to

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/debugfs: Print sink PSR status

== Series Details == Series: series starting with [1/2] drm/i915/debugfs: Print sink PSR status URL : https://patchwork.freedesktop.org/series/40977/ State : failure == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-64x64-suspend: dmesg-warn

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function

== Series Details == Series: series starting with [01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function URL : https://patchwork.freedesktop.org/series/40978/ State : warning == Summary == $ dim checkpatch origin/drm-tip 499cc3f929a4 drm/i915/psr: Move specific HSW+ WARN_ON to

[Intel-gfx] [PATCH 07/11] drm/i915/dp: Exit PSR before do a aux channel transaction

When PSR/PSR2 is enabled hardware can do aux ch transactions by it self. Spec requires that PSR is inactive before do any aux ch transaction in HSW and BDW, for skl+ there is a aux ch mutex but the use is not recommended. So exiting PSR/PSR2 and waiting the transition to inactive to prevent any

[Intel-gfx] [PATCH 06/11] drm/i915/psr: Add intel_psr_activate_block_get()/put()

intel_psr_activate_block_get() should be called when by some reason PSR should not be activated for some time, it will increment counter and it should the decremented by intel_psr_activate_block_put() when PSR can be activated again. intel_psr_activate_block_put() will not actually activate PSR,

[Intel-gfx] [PATCH 02/11] drm/i915/psr: Move PSR exit specific code to hardware specific function

To proper execute PSR exit it was using 'if (HAS_DDI(dev_priv))' to differentiate between VLV/CHV and HSW+ hardware, so here moving each hardware handling to his own function. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc:

[Intel-gfx] [PATCH 09/11] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink

eDP spec states that sink device will do a short pulse in HPD line when there is a PSR/PSR2 error that needs to be handled by source, this is handling the first and most simples error: DP_PSR_SINK_INTERNAL_ERROR. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan

[Intel-gfx] [PATCH 08/11] drm/i915: Keep IGT PSR and frontbuffer tests functional

'drm/i915/dp: Exit PSR before do a aux channel transaction' cause all IGT PSR and frontbuffer tracking tests to not be userful. Those tests depend in reading the calculated CRC value of the frontbuffer in sink and doing a aux transaction now causes the PSR to exit. So any bug in software and

[Intel-gfx] [PATCH 03/11] drm/i915/psr: Share code between disable and exit

The disable and exit sequence are very similar with a lot common code between both, so here sharing the code. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi ---

[Intel-gfx] [PATCH 05/11] drm/i915/psr: Export intel_psr_activate/exit()

Export this functions so other modules can activate and exit PSR. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_drv.h | 2 +

[Intel-gfx] [PATCH 04/11] drm/i915/psr: Remove intel_crtc_state parameter from disable()

It is not necessary as is possible to get the pipe information from intel_dp. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.h | 3 +--

[Intel-gfx] [PATCH 10/11] drm/i915/psr: Handle PSR RFB storage error

Sink will interrupt source when it have any problem saving or reading the remote frame buffer. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_psr.c | 10

[Intel-gfx] [PATCH 01/11] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function

It was reading some random register in VLV and CHV. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_psr.c | 9 + 1 file changed, 5 insertions(+), 4

[Intel-gfx] [PATCH 11/11] drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side

Sink can be configured to calculate the CRC over the static frame and compare with the CRC calculated and transmited in the VSC SDP by source, if there is a mismatch sink will do a short pulse in HPD and set DP_PSR_LINK_CRC_ERROR on DP_PSR_ERROR_STATUS. Spec: 7723 Signed-off-by: José Roberto de

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/debugfs: Print sink PSR status

== Series Details == Series: series starting with [1/2] drm/i915/debugfs: Print sink PSR status URL : https://patchwork.freedesktop.org/series/40977/ State : success == Summary == Series 40977v1 series starting with [1/2] drm/i915/debugfs: Print sink PSR status

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/debugfs: Print sink PSR status

== Series Details == Series: series starting with [1/2] drm/i915/debugfs: Print sink PSR status URL : https://patchwork.freedesktop.org/series/40977/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9444b2175c0a drm/i915/debugfs: Print sink PSR status 6d65247b0089

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw (rev2)

== Series Details == Series: series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw (rev2) URL : https://patchwork.freedesktop.org/series/40704/ State : failure == Summary == Applying: drm/i915: Enable edp psr error interrupts on hsw Applying: drm/i915: Enable edp psr

Re: [Intel-gfx] [PATCH v3] drm/i915/psr: Control PSR interrupts via debugfs

On Fri, 2018-03-30 at 14:15 -0700, Dhinakaran Pandiyan wrote: > Interrupts other than the one for AUX errors are required only for debug, > so unmask them via debugfs when the user requests debug. > > User can make such a request with > echo 1 > /dri/0/i915_edp_psr_debug > > There are no

[Intel-gfx] [PATCH 2/2] drm/i915/psr/cnl: Set y-coordinate as valid in SDP

This was my bad, spec says that the name of this bit is 'Y-coordinate valid' but the values for it is: 0: Include Y-coordinate valid eDP1.4a 1: Do not include Y-coordinate valid eDP 1.4 So renaming the bit and not setting it. Cc: Dhinakaran Pandiyan Signed-off-by:

[Intel-gfx] [PATCH 1/2] drm/i915/debugfs: Print sink PSR status

IGT tests could be improved with sink status, knowing for sure that hardware have activate or exit PSR. Reviewed-by: Dhinakaran Pandiyan Cc: Rodrigo Vivi Signed-off-by: José Roberto de Souza ---

[Intel-gfx] [PATCH v3] drm/i915/psr: Control PSR interrupts via debugfs

Interrupts other than the one for AUX errors are required only for debug, so unmask them via debugfs when the user requests debug. User can make such a request with echo 1 > /dri/0/i915_edp_psr_debug There are no locks to serialize PSR debug enabling from irq_postinstall() and debugfs for

Re: [Intel-gfx] [PATCH v3 10/10] drm/i915/debugfs: Print sink PSR status

On Fri, 2018-03-30 at 19:19 +, Souza, Jose wrote: > On Fri, 2018-03-30 at 11:28 -0700, Pandiyan, Dhinakaran wrote: > > On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote: > > > IGT tests could be improved with sink status, knowing for sure that > > > hardware have activate or

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add Exec param to control data port coherency. (rev2)

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev2) URL : https://patchwork.freedesktop.org/series/40181/ State : failure == Summary == Possible new issues: Test gem_exec_params: Subgroup invalid-flag: pass -> FAIL

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

On 30/03/18 08:42, Lis, Tomasz wrote: 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

Re: [Intel-gfx] [PATCH v3 10/10] drm/i915/debugfs: Print sink PSR status

On Fri, 2018-03-30 at 11:28 -0700, Pandiyan, Dhinakaran wrote: > On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote: > > IGT tests could be improved with sink status, knowing for sure that > > hardware have activate or exit PSR. > > > > Cc: Dhinakaran Pandiyan

Re: [Intel-gfx] [PATCH i-g-t v3] intel-gpu-top: Rewrite the tool to be safe to use

>Четверг, 29 марта 2018, 21:46 +03:00 от Tvrtko Ursulin : > >+#define engine_ptr(engines, n) \ >+((struct engine *)((unsigned char *)(>engine) + (n) * sizeof(struct >engine))) I think (>engine + (n)) is easier to read. >+if (fd < 0 && !cnt->optional) >+return -1; I've

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

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add Exec param to control data port coherency. (rev2)

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev2) URL : https://patchwork.freedesktop.org/series/40181/ State : success == Summary == Series 40181v2 drm/i915: Add Exec param to control data port coherency.

Re: [Intel-gfx] [PATCH v3 10/10] drm/i915/debugfs: Print sink PSR status

On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote: > IGT tests could be improved with sink status, knowing for sure that > hardware have activate or exit PSR. > > Cc: Dhinakaran Pandiyan > Cc: Rodrigo Vivi > Signed-off-by:

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add Exec param to control data port coherency. (rev2)

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev2) URL : https://patchwork.freedesktop.org/series/40181/ State : warning == Summary == $ dim checkpatch origin/drm-tip 415de02a8f37 drm/i915: Add Exec param to control data port coherency. -:14:

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

On Fri, 2018-03-30 at 10:36 -0700, Pandiyan, Dhinakaran wrote: > > > 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

Re: [Intel-gfx] [PATCH v3 09/10] drm/i915/psr: Set DPCD PSR2 enable bit when needed

On Wed, Mar 28, 2018 at 03:30:45PM -0700, José Roberto de Souza wrote: > In the 2 eDP1.4a pannels tested set or not set bit have no effect > but is better set it and comply with specification. > > Signed-off-by: José Roberto de Souza > Cc: Dhinakaran Pandiyan

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

[Intel-gfx] ✗ Fi.CI.IGT: failure 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 : failure == Summary == Possible new issues: Test gem_ctx_param: Subgroup

[Intel-gfx] ✓ Fi.CI.BAT: success 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 : success == Summary == Series 40961v1 series starting with [01/18] drm/i915/selftests: Avoid

[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 v12 05/17] drm/i915/guc/slpc: Add SLPC communication interfaces

On 3/30/2018 7:07 PM, Michal Wajdeczko wrote: On Fri, 30 Mar 2018 10:31:50 +0200, Sagar Arun Kamble wrote: diff --git a/drivers/gpu/drm/i915/intel_guc_slpc.h b/drivers/gpu/drm/i915/intel_guc_slpc.h index 66c76fe..81250c0 100644 ---

[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 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 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 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 14/18] 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] [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 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 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 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] [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

[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 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 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] ✗ 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 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

[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

[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] [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

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

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

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 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:

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

[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

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] 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

[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 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: 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

[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

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

[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

[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] 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

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

[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:

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] 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] ✓ 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 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

[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.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 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 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 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] 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 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

  1   2   >