[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Reset the hangcheck timestamp before repeating a seqno

== Series Details == Series: series starting with [1/2] drm/i915: Reset the hangcheck timestamp before repeating a seqno URL : https://patchwork.freedesktop.org/series/42598/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4125_full -> Patchwork_8885_full = == Summary - WARN

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

On Wed, 02 May 2018, Rodrigo Vivi wrote: > On Wed, May 02, 2018 at 02:43:29PM +0530, vathsala nagaraju wrote: >> From: Vathsala Nagaraju >> >> For psr block #9, the vbt description has moved to options [0-3] for >> TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt >> structure

Re: [Intel-gfx] [PATCH] drm/i915: Correctly populate user mode h/vdisplay with pipe src size during readout

On Wed, 02 May 2018, Chris Wilson wrote: > Quoting Ville Syrjälä (2018-05-02 17:14:21) >> On Wed, May 02, 2018 at 04:57:09PM +0100, Chris Wilson wrote: >> > Quoting Ville Syrjälä (2018-05-02 16:52:41) >> > > On Wed, May 02, 2018 at 04:33:30PM +0100, Chris Wilson wrote: >> > > > Quoting Ville Syrja

[Intel-gfx] [PATCH 47/71] drm/i915: Enabling rc6 and rps have different requirements, so separate them

On Ironlake, we are required to not enable rc6 until the GPU is loaded with a valid context; after that point it can start to use a powersaving context for rc6. This seems a reasonable requirement to impose on all generations as we are already priming the system by loading a context on resume. We c

[Intel-gfx] [PATCH 51/71] drm/i915: Pull IPS into GT power management

IPS was the precursor to RPS on Ironlake. It serves the same function, and so should be pulled under the intel_gt_pm umbrella. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h| 27 -- drivers/gpu/drm/i915/i915_irq.c| 21 drivers/gpu/drm/i915/intel_gt_pm.c

[Intel-gfx] [PATCH 50/71] drm/i915: Rename rps min/max frequencies

In preparation for more layers of limits, rename the existing limits to hw and user. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 34 --- drivers/gpu/drm/i915/i915_pmu.c | 4 +- drivers/gpu/drm/i915/i915_sysfs.c | 23 ++--- drivers/gpu/drm/i915/intel_gt_pm.

[Intel-gfx] [PATCH 45/71] drm/i915: Reorder GT interface code

Try to order the intel_gt_pm code to match the order it is used: init enable disable cleanup Signed-off-by: Chris Wilson Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_gt_pm.c | 170 ++--- drivers/gpu/drm/i915/intel_gt_pm.h

[Intel-gfx] [PATCH 44/71] drm/i915: Remove defunct intel_suspend_gt_powersave()

Since commit b7137e0cf1e5 ("drm/i915: Defer enabling rc6 til after we submit the first batch/context"), intel_suspend_gt_powersave() has been a no-op. As we still do not need to do anything explicitly on suspend (we do everything required on idling), remove the defunct function. References: b7137e

[Intel-gfx] [PATCH 49/71] drm/i915: Refactor frequency bounds computation

When choosing the initial frequency in intel_gt_pm_busy() we also need to calculate the current min/max bounds. As this calculation is going to become more complex with the intersection of several different limits, refactor it to a common function. The alternative wold be to feed the initial recloc

[Intel-gfx] [PATCH 43/71] drm/i915: Track HAS_RPS alongside HAS_RC6 in the device info

For consistency (and elegance!), add intel_device_info.has_rps. The immediate boon is that RPS support is now emitted along the other capabilities in the debug log and after errors. Signed-off-by: Chris Wilson Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_drv.h | 2 ++

[Intel-gfx] [PATCH 48/71] drm/i915: Simplify rc6/rps enabling

As we know that whenever the GT is awake, rc6 and rps are enabled (if available), then we can remove the individual tracking and enabling to the gen6_rps_busy/gen6_rps_idle() (now called intel_gt_pm_busy and intel_gt_pm_idle) entry points. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i91

[Intel-gfx] [PATCH 46/71] drm/i915: Split control of rps and rc6

Allow ourselves to individually toggle rps or rc6. This will be used later when we want to enable rps/rc6 at different phases during the device bring up. Whilst here, convert the intel_$verb_gt_powersave over to intel_gt_pm_$verb scheme. v2: Resurrect llc_pstate, we will need to restore state on

[Intel-gfx] [PATCH 37/71] drm/i915: Generalize i915_gem_sanitize() to reset contexts

While we believe that we need to always reset the GPU to scrub the state on transition to/from the driver, it is essential when we enable contexts. Generalize the gen test to be on context-support instead. References: d2b4b97933f5 ("drm/i915: Record the default hw state after reset upon load" Sig

[Intel-gfx] [PATCH 29/71] Revert "drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3"

With the vlv sideband fixed to avoid sleeping while we talk to the punit, the system should be much more stable and be able to utilise the punit without risk. This reverts commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3") References: 6067a27d1f01 ("drm/i915: Av

[Intel-gfx] [PATCH 36/71] drm/i915: Record logical context support in driver caps

Avoid looking at the magical engines[RCS] to decide if the HW and driver supports logical contexts, and instead record that knowledge during initialisation. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem_context.c | 5 ++--- drivers

[Intel-gfx] [PATCH 23/71] 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 ba

[Intel-gfx] [PATCH 32/71] drm/i915: Merge sbi read/write into a single accessor

Since intel_sideband_read and intel_sideband_write differ by only a couple of lines (depending on whether we feed the value in or out), merge the two into a single common accessor. v2: Restore vlv_flisdsi_read() lost during rebasing. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_si

[Intel-gfx] [PATCH 35/71] drm/i915: Mark up Ironlake ips with rpm wakerefs

Currently Ironlake operates under the assumption that rpm awake (and its error checking is disabled). As such, we have missed a few places where we access registers without taking the rpm wakeref and thus trigger warnings. intel_ips being one culprit. As this involved adding a potentially sleeping

[Intel-gfx] [PATCH 34/71] drm/i915: Move sandybride pcode access to intel_sideband.c

sandybride_pcode is another sideband, so move it to their new home. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 10 -- drivers/gpu/drm/i915/intel_hdcp.c | 3 +- drivers/gpu/drm/i915/intel_pm.c | 194 -- drivers/gpu/drm/i915/intel_s

[Intel-gfx] [PATCH 38/71] drm/i915: Enable render context support for Ironlake (gen5)

Ironlake does support being able to saving and reloading context specific registers between contexts, providing isolation of the basic GPU state (as programmable by userspace). This allows userspace to assume that the GPU retains their state from one batch to the next, minimising the amount of stat

[Intel-gfx] [PATCH 42/71] drm/i915: Move all the RPS irq handlers to intel_gt_pm

Since all the RPS handling code is in intel_gt_pm, move the irq handlers there as well so that it all contained within one file. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 4 - drivers/gpu/drm/i915/i915_irq.c | 315 +++- drivers/gpu/dr

[Intel-gfx] [PATCH 30/71] drm/i915: Replace pcu_lock with sb_lock

We now have two locks for sideband access. The general one covering sideband access across all generation, sb_lock, and a specific one covering sideband access via the punit on vlv/chv. After lifting the sb_lock around the punit into the callers, the pcu_lock is now redudant and can be separated fr

[Intel-gfx] [PATCH 25/71] drm/i915: Disable preemption and sleeping while using the punit sideband

While we talk to the punit over its sideband, we need to prevent the cpu from sleeping in order to prevent a potential machine hang. Note that by itself, it appears that pm_qos_update_request (via intel_idle) doesn't provide a sufficient barrier to ensure that all core are indeed awake (out of Cst

[Intel-gfx] [PATCH 31/71] drm/i915: Separate sideband declarations to intel_sideband.h

Split the sideback declarations out of the ginormous i915_drv.h Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 62 - drivers/gpu/drm/i915/i915_sysfs.c | 2 + drivers/gpu/drm/i915/intel_cdclk.c

[Intel-gfx] [PATCH 33/71] drm/i915: Merge sandybridge_pcode_(read|write)

These routines are identical except in the nature of the value parameter. For writes it is a pure in-param, but for a read, we need an out-param. Since they differ in a single line, merge the two routines into one. Signed-off-by: Chris Wilson Reviewed-by: Imre Deak --- drivers/gpu/drm/i915/inte

[Intel-gfx] [PATCH 39/71] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)

Broadwater and the rest of gen4 do support being able to saving and reloading context specific registers between contexts, providing isolation of the basic GPU state (as programmable by userspace). This allows userspace to assume that the GPU retains their state from one batch to the next, minimis

[Intel-gfx] [PATCH 41/71] drm/i915: Move rps worker to intel_gt_pm.c

The RPS worker exists to do the bidding of the GT powermanagement, so move it from i915_irq to intel_gt_pm.c where it can be hidden from the rest of the world. The goal being that the RPS worker is the one true way though which all RPS updates are coordinated. Signed-off-by: Chris Wilson Reviewed

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

One usecase would be to couple in via EGL_NV_context_priority_realtime in userspace to provide some QoS guarantees in conjunction with setting the highest priority. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c| 22 ++ drivers/gpu/drm/i915/i915_gem_context.h

[Intel-gfx] [PATCH 27/71] drm/i915: Lift sideband locking for vlv_punit_(read|write)

Lift the sideband acquisition for vlv_punit_read and vlv_punit_write into their callers, so that we can lock the sideband once for a sequence of operations, rather than perform the heavyweight acquisition on each request. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c |

[Intel-gfx] [PATCH 26/71] drm/i915: Lift acquiring the vlv punit magic to a common sb-get

As we now employ a very heavy pm_qos around the punit access, we want to minimise the number of synchronous requests by performing one for the whole punit sequence rather than around individual accesses. The sideband lock is used for this, so push the pm_qos into the sideband lock acquisition and r

[Intel-gfx] [PATCH 22/71] 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 trigg

[Intel-gfx] [PATCH 28/71] drm/i915: Reduce RPS update frequency on Valleyview/Cherryview

Valleyview and Cherryview update the GPU frequency via the punit, which is very expensive as we have to ensure the cores do not sleep during the comms. If we perform frequent RPS evaluations, the frequent punit requests cause measurable system overhead for little benefit, so increase the evaluation

[Intel-gfx] [PATCH 10/71] 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 Cc: Michał Winiarski Revi

[Intel-gfx] [PATCH 16/71] 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 -- 1 file changed, 4

[Intel-gfx] [PATCH 12/71] drm/i915: Split execlists/guc reset preparations

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 Cc: Michał Winiarski CC:

[Intel-gfx] [PATCH 11/71] 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 Thierry Cc: Jeff McGee Reviewed-by: Jeff McGee --- dr

[Intel-gfx] [PATCH 04/71] drm/i915: Keep one request in our ring_list

Don't pre-emptively retire the oldest request in our ring's list if it is the only request. We keep various bits of state alive using the active reference from the request and would rather transfer that state over to a new request rather than the more involved process of retiring and reacquiring it

[Intel-gfx] [PATCH 18/71] drm/i915/guc: Make submission tasklet hardirq safe

Prepare to allow the GuC submission to be run from underneath a hardirq timer context (and not just the current softirq context) as is required for fast preemption resets. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_guc_submission.c | 5 +++-- 1 file changed, 3 insertions(+), 2 de

[Intel-gfx] [PATCH 01/71] drm/i915/execlists: Drop preemption arbitrations points along the ring

Limit the arbitration (where preemption may occur) to inside the batch, and prevent it from happening on the pipecontrols/flushes we use to write the breadcrumb seqno. Once the user batch is complete, we have nothing left to do but serialise and emit the breadcrumb; switching contexts at this point

[Intel-gfx] [PATCH 13/71] 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 CC: Michel Thierry Cc: Jeff McGee -

[Intel-gfx] [PATCH 14/71] 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 ta

[Intel-gfx] [PATCH 20/71] 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 bef

[Intel-gfx] [PATCH 19/71] 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 +++-- 1 file changed, 3 inserti

[Intel-gfx] [PATCH 17/71] drm/i915/execlists: Make submission tasklet hardirq safe

Prepare to allow the execlists submission to be run from underneath a hardirq timer context (and not just the current softirq context) as is required for fast preemption resets. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletio

[Intel-gfx] [PATCH 05/71] drm/i915/execlists: Disable submission tasklets when rescheduling

As we reschedule the requests, we do not want the submission tasklet running until we finish updating the priority chains. (We start rewriting priorities from the oldest, but the dequeue looks at the most recent in-flight, so there is a small race condition where dequeue may decide that preemption

[Intel-gfx] [PATCH 07/71] drm/i915: Move request->ctx aside

In the next patch, we want to store the intel_context pointer inside i915_request, as it is frequently access via a convoluted dance when submitting the request to hw. Having two context pointers inside i915_request leads to confusion so first rename the existing i915_gem_context pointer to i915_re

[Intel-gfx] [PATCH 21/71] drm/i915/execlists: Try preempt-reset from hardirq timer 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 Cc: Mika Kuoppala

[Intel-gfx] [PATCH 15/71] 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 08/71] drm/i915: Move fiddling with engine->last_retired_context

Move the knowledge about resetting the current context tracking on the engine from inside i915_gem_context.c into intel_engine_cs.c Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_context.c | 12 ++-- drivers/gpu/drm/i915/intel_engine_cs.c | 23

[Intel-gfx] [PATCH 02/71] drm/i915/execlists: Emit i915_trace_request_out for preemption

Move the tracepoint into the common execlists_context_schedule_out() and call it from preemption completion as well. A small bit of refactoring code should help with when tracing, or else we end up with requests mysteriously disappearing and some being emitted to HW multiple times. Reported-by: Tv

[Intel-gfx] [PATCH 06/71] drm/i915: Detect if we missed kicking the execlists tasklet

If inside hangcheck we see that the engine has paused, but there is an execlists interrupt still pending, we know that the tasklet did not fire. Dump the GEM trace along with the current engine state, and kick the tasklet to recovery without having to go through a GPU reset. Signed-off-by: Chris W

[Intel-gfx] [PATCH 09/71] drm/i915: Store a pointer to intel_context in i915_request

To ease the frequent and ugly pointer dance of &request->gem_context->engine[request->engine->id] during request submission, store that pointer as request->hw_context. One major advantage that we will exploit later is that this decouples the logical context state from the engine itself. v2: Set mo

[Intel-gfx] [PATCH 03/71] drm/i915: Lazily unbind vma on close

When userspace is passing around swapbuffers using DRI, we frequently have to open and close the same object in the foreign address space. This shows itself as the same object being rebound at roughly 30fps (with a second object also being rebound at 30fps), which involves us having to rewrite the

Re: [Intel-gfx] [PATCH] drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear()

On Wed, May 02, 2018 at 09:32:47PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Clear the old_state and new_state pointers for every object in > drm_atomic_state_default_clear(). Otherwise > drm_atomic_get_{new,old}_*_state() will hand out stale pointers to > anyone who hasn't first conf

Re: [Intel-gfx] [PATCH v13 08/10] drm: Expose modes with aspect ratio, only if requested

On Wed, May 02, 2018 at 12:20:20PM +0530, Nautiyal, Ankit K wrote: > From: Ankit Nautiyal > > We parse the EDID and add all the modes in the connector's modelist. > This adds CEA modes with aspect ratio information too, regardless of > whether user space requested this information or not. > > Th

[Intel-gfx] ✓ Fi.CI.IGT: success for Workarounds for Icelake (rev2)

== Series Details == Series: Workarounds for Icelake (rev2) URL : https://patchwork.freedesktop.org/series/42055/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4124_full -> Patchwork_8883_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8883_ful

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/userptr: reject zero user_size (rev2)

== Series Details == Series: drm/i915/userptr: reject zero user_size (rev2) URL : https://patchwork.freedesktop.org/series/42586/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4124_full -> Patchwork_8882_full = == Summary - WARNING == Minor unknown changes coming with Pa

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

On Thursday 03 May 2018 02:45 AM, Rodrigo Vivi wrote: On Wed, May 02, 2018 at 02:43:29PM +0530, vathsala nagaraju wrote: From: Vathsala Nagaraju For psr block #9, the vbt description has moved to options [0-3] for TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt structure.

[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable HuC authentication in Icelake (rev2)

== Series Details == Series: Enable HuC authentication in Icelake (rev2) URL : https://patchwork.freedesktop.org/series/42433/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4123_full -> Patchwork_8881_full = == Summary - FAILURE == Serious unknown changes coming with Pat

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear()

== Series Details == Series: drm/atomic: Clean old_state/new_state in drm_atomic_state_default_clear() URL : https://patchwork.freedesktop.org/series/42588/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4123_full -> Patchwork_8880_full = == Summary - SUCCESS == No regre

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl, x86/gpu: implement ICL stolen memory support

== Series Details == Series: drm/i915/icl, x86/gpu: implement ICL stolen memory support URL : https://patchwork.freedesktop.org/series/42607/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4126 -> Patchwork_8891 = == Summary - SUCCESS == No regressions found. External

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Stash desired logical vco in a reliable place. (rev2)

== Series Details == Series: drm/i915: Stash desired logical vco in a reliable place. (rev2) URL : https://patchwork.freedesktop.org/series/42537/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4123_full -> Patchwork_8878_full = == Summary - WARNING == Minor unknown chang

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl, x86/gpu: implement ICL stolen memory support

== Series Details == Series: drm/i915/icl, x86/gpu: implement ICL stolen memory support URL : https://patchwork.freedesktop.org/series/42607/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6b63a3791d11 drm/i915/icl, x86/gpu: implement ICL stolen memory support -:33: WARNING:COMM

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update (rev2)

== Series Details == Series: drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update (rev2) URL : https://patchwork.freedesktop.org/series/42527/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4126 -> Patchwork_8890 = == Summary - SUCCESS ==

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update (rev2)

== Series Details == Series: drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update (rev2) URL : https://patchwork.freedesktop.org/series/42527/ State : warning == Summary == $ dim checkpatch origin/drm-tip 48983ee8c47c drm/i915: Remove redundant check for neg

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Lazily unbind vma on close

== Series Details == Series: series starting with [1/2] drm/i915: Lazily unbind vma on close URL : https://patchwork.freedesktop.org/series/42601/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4126 -> Patchwork_8889 = == Summary - WARNING == Minor unknown changes coming

[Intel-gfx] [PATCH] drm/i915/icl, x86/gpu: implement ICL stolen memory support

ICL changes the registers and addresses to 64 bits. I also briefly looked at implementing an u64 version of the PCI config read functions, but I concluded this wouldn't be trivial, so it's not worth doing it for a single user that can't have any racing problems while reading the register in two se

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Micro-optimise i915_request_retire()

== Series Details == Series: drm/i915: Micro-optimise i915_request_retire() URL : https://patchwork.freedesktop.org/series/42581/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4123_full -> Patchwork_8877_full = == Summary - SUCCESS == No regressions found. External UR

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Lazily unbind vma on close

== Series Details == Series: series starting with [1/2] drm/i915: Lazily unbind vma on close URL : https://patchwork.freedesktop.org/series/42601/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Lazily unbind vma on close -drivers/gpu/drm/i915/selftests/../i915_drv.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Emit i915_trace_request_out for preemption

== Series Details == Series: drm/i915/execlists: Emit i915_trace_request_out for preemption URL : https://patchwork.freedesktop.org/series/42600/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4126 -> Patchwork_ = == Summary - WARNING == Minor unknown changes coming w

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: configure the transcoder clocks before touching pipeconf on HSW+ (rev2)

== Series Details == Series: drm/i915: configure the transcoder clocks before touching pipeconf on HSW+ (rev2) URL : https://patchwork.freedesktop.org/series/42436/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4126 -> Patchwork_8887 = == Summary - FAILURE == Serious un

[Intel-gfx] [PATCH v2] drm/i915: Remove redundant check for negative timeout while doing an atomic pipe update

From: Tarun No functional changes, just a minor knit. Stumbled across the kernel doc for schedule_timeout() which quotes "In all cases the return value is guaranteed to be non-negative". Also, the return code of schedule_timeout() already checks for negative values "return timeout < 0 ? 0 : timeo

[Intel-gfx] [PATCH 1/2] drm/i915: Lazily unbind vma on close

When userspace is passing around swapbuffers using DRI, we frequently have to open and close the same object in the foreign address space. This shows itself as the same object being rebound at roughly 30fps (with a second object also being rebound at 30fps), which involves us having to rewrite the

[Intel-gfx] [PATCH 2/2] drm/i915: Keep one request in our ring_list

Don't pre-emptively retire the oldest request in our ring's list if it is the only request. We keep various bits of state alive using the active reference from the request and would rather transfer that state over to a new request rather than the more involved process of retiring and reacquiring it

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Add configuring MOCS in new Icelake engines

== Series Details == Series: drm/i915/icl: Add configuring MOCS in new Icelake engines URL : https://patchwork.freedesktop.org/series/42599/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4125 -> Patchwork_8886 = == Summary - WARNING == Minor unknown changes coming with P

[Intel-gfx] [CI] drm/i915/execlists: Emit i915_trace_request_out for preemption

Move the tracepoint into the common execlists_context_schedule_out() and call it from preemption completion as well. A small bit of refactoring code should help with when tracing, or else we end up with requests mysteriously disappearing and some being emitted to HW multiple times. Reported-by: Tv

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move timeline from GTT to ring URL : https://patchwork.freedesktop.org/series/42576/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4122_full -> Patchwork_8876_full = == Summary - FAILURE == Serious unkn

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: Add configuring MOCS in new Icelake engines

== Series Details == Series: drm/i915/icl: Add configuring MOCS in new Icelake engines URL : https://patchwork.freedesktop.org/series/42599/ State : warning == Summary == $ dim checkpatch origin/drm-tip fc76506254fe drm/i915/icl: Add configuring MOCS in new Icelake engines -:6: WARNING:COMMIT_

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Reset the hangcheck timestamp before repeating a seqno

== Series Details == Series: series starting with [1/2] drm/i915: Reset the hangcheck timestamp before repeating a seqno URL : https://patchwork.freedesktop.org/series/42598/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4125 -> Patchwork_8885 = == Summary - SUCCESS ==

[Intel-gfx] [PATCH CI] drm/i915/icl: Add configuring MOCS in new Icelake engines

From: Tomasz Lis In Icelake, there are more engines on which Memory Object Control States need to be configured. Besides adding Icelake under Skylake config, the patch makes sure MOCS register addresses for the new engines are properly defined. Additional patch might be need later, in case the s

Re: [Intel-gfx] [PATCH] drm/i915: Wait for PSR exit before checking for vblank evasion for an atomic update

On Wed, May 02, 2018 at 01:04:06PM -0700, Vivi, Rodrigo wrote: > On Wed, May 02, 2018 at 09:51:43PM +0300, Ville Syrjälä wrote: > > On Wed, May 02, 2018 at 11:19:14AM -0700, Tarun Vyas wrote: > > > On Mon, Apr 30, 2018 at 10:19:33AM -0700, Rodrigo Vivi wrote: > > > > On Sun, Apr 29, 2018 at 09:00:1

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: configure the transcoder clocks before touching pipeconf on HSW+ (rev2)

== Series Details == Series: drm/i915: configure the transcoder clocks before touching pipeconf on HSW+ (rev2) URL : https://patchwork.freedesktop.org/series/42436/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4125 -> Patchwork_8884 = == Summary - FAILURE == Serious un

Re: [Intel-gfx] [PATCH] drm/i915: enable the pipe/transcoder/planes later on HSW+

On Wed, May 02, 2018 at 02:58:51PM -0700, Paulo Zanoni wrote: > For all platforms that run haswell_crtc_enable, our spec tells us to > configure the transcoder clocks and do link training before it tells > us to set pipeconf and the other pipe/transcoder/plane registers. > > Starting from Icelake,

Re: [Intel-gfx] [PATCH] drm/i915: enable the pipe/transcoder/planes later on HSW+

On Wed, May 02, 2018 at 02:58:51PM -0700, Paulo Zanoni wrote: > For all platforms that run haswell_crtc_enable, our spec tells us to > configure the transcoder clocks and do link training before it tells > us to set pipeconf and the other pipe/transcoder/plane registers. oh! I remember this order

[Intel-gfx] [PATCH 2/2] drm/i915: Mark the hangcheck as idle when unparking the engines

As we unpark the engines and are about to begin a new cycle of activity, mark the current status of the hangceck as idle so that we avoid carrying over a stale timestamp/action into the next cycle. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++

[Intel-gfx] [PATCH 1/2] drm/i915: Reset the hangcheck timestamp before repeating a seqno

In the unusual circumstance where we reuse a seqno (for example, in igt), make sure that we reset the hangcheck timestamp before it sees the same seqno again. References: https://bugs.freedesktop.org/show_bug.cgi?id=106215 Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i

[Intel-gfx] [PATCH] drm/i915: enable the pipe/transcoder/planes later on HSW+

For all platforms that run haswell_crtc_enable, our spec tells us to configure the transcoder clocks and do link training before it tells us to set pipeconf and the other pipe/transcoder/plane registers. Starting from Icelake, we get machine hangs if we try to touch the pipe/transcoder registers w

Re: [Intel-gfx] [PATCH] drm/i915: Silence debugging DRM_ERROR for failing to suspend vlv powerwells

Quoting Chris Wilson (2018-04-09 10:54:46) > Quoting Chris Wilson (2018-04-09 10:49:05) > > If we try to suspend a wedged device following a GPU reset failure, we > > will also fail to turn off the rc6 powerwells (on vlv), leading to a > > *ERROR*. This is quite expected in this case, so the best w

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

On Wed, May 02, 2018 at 02:43:29PM +0530, vathsala nagaraju wrote: > From: Vathsala Nagaraju > > For psr block #9, the vbt description has moved to options [0-3] for > TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt > structure. Since spec does not mention from which VBT ver

Re: [Intel-gfx] [PATCH] drm/i915: configure the transcoder clocks before touching pipeconf on HSW+

Em Seg, 2018-04-30 às 21:12 +0300, Ville Syrjälä escreveu: > On Fri, Apr 27, 2018 at 04:12:08PM -0700, Paulo Zanoni wrote: > > For all platforms that run haswell_crtc_enable, our spec tells us > > to > > configure the transcoder clocks before it tells us to set pipeconf > > and > > the other pipe/t

[Intel-gfx] ✓ Fi.CI.BAT: success for Workarounds for Icelake (rev2)

== Series Details == Series: Workarounds for Icelake (rev2) URL : https://patchwork.freedesktop.org/series/42055/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4124 -> Patchwork_8883 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.free

Re: [Intel-gfx] [PATCH 02/22] drm/i915/icl: Enable Sampler DFR

On Wed, May 02, 2018 at 01:34:01PM -0700, Oscar Mateo wrote: > Sampler Dynamic Frequency Rebalancing (DFR) aims to reduce Sampler > power by dynamically changing its clock frequency in low-throughput > conditions. This patches enables it by default on Gen11. > > v2: Wrong operation to clear the bi

Re: [Intel-gfx] [PATCH 10/22] drm/i915/icl: Wa_1406680159

On Wed, May 02, 2018 at 01:34:09PM -0700, Oscar Mateo wrote: > Disable GWL clock gating to prevent two different issues that > might cause hangs. > > Please notice that one of the issues is pre-production only. > > v2: Rebased on top of the WA refactoring > v3: Wa_2201832410 officially merged wit

[Intel-gfx] [PATCH i-g-t] igt/gem_exec_latency: Robustify measurements

Repeat the latency measurements and present the median over many so that the results are more reliable. Signed-off-by: Chris Wilson --- tests/gem_exec_latency.c | 155 ++- 1 file changed, 70 insertions(+), 85 deletions(-) diff --git a/tests/gem_exec_latency.c

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Workarounds for Icelake (rev2)

== Series Details == Series: Workarounds for Icelake (rev2) URL : https://patchwork.freedesktop.org/series/42055/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/icl: Introduce initial Icelake Workarounds -drivers/gpu/drm/i915/selftests/../i915_drv.h:3663:16: warning

Re: [Intel-gfx] [PATCH v2 00/22] Workarounds for Icelake

On 5/2/2018 1:40 PM, Chris Wilson wrote: Quoting Oscar Mateo (2018-05-02 21:33:59) List of GT workarounds for Icelake that we have been carrying in internal. (Is (checkpatch (((going to complain) (that this isn't)) (lisp? -Chris Maybe. Or maybe checkpatch has given

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Workarounds for Icelake (rev2)

== Series Details == Series: Workarounds for Icelake (rev2) URL : https://patchwork.freedesktop.org/series/42055/ State : warning == Summary == $ dim checkpatch origin/drm-tip fb5717243f07 drm/i915/icl: Introduce initial Icelake Workarounds -:50: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p'

Re: [Intel-gfx] [PATCH] drm/i915/firmware: Correct URL for firmware

On Tue, May 01, 2018 at 09:59:10AM -0700, Srivatsa, Anusha wrote: > > > >-Original Message- > >From: Vivi, Rodrigo > >Sent: Monday, April 30, 2018 5:36 PM > >To: Srivatsa, Anusha > >Cc: intel-gfx@lists.freedesktop.org > >Subject: Re: [PATCH] drm/i915/firmware: Correct URL for firmware >

Re: [Intel-gfx] [PATCH v2 00/22] Workarounds for Icelake

Quoting Oscar Mateo (2018-05-02 21:33:59) > List of GT workarounds for Icelake that we have been carrying in internal. (Is (checkpatch (((going to complain) (that this isn't)) (lisp? -Chris ___ Intel-gfx mailing list Intel-gfx@lists

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/userptr: reject zero user_size (rev2)

== Series Details == Series: drm/i915/userptr: reject zero user_size (rev2) URL : https://patchwork.freedesktop.org/series/42586/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4124 -> Patchwork_8882 = == Summary - WARNING == Minor unknown changes coming with Patchwork_88

  1   2   3   >