Re: [Intel-gfx] [PATCH 3/4] drm/i915: Store a pointer to intel_context in i915_request

On 2018.05.17 22:26:32 +0100, Chris Wilson wrote: > To ease the frequent and ugly pointer dance of > >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

[Intel-gfx] ✓ Fi.CI.IGT: success for DRM helpers for Display Stream Compression PPS infoframes (rev6)

== Series Details == Series: DRM helpers for Display Stream Compression PPS infoframes (rev6) URL : https://patchwork.freedesktop.org/series/42968/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4201_full -> Patchwork_9040_full = == Summary - WARNING == Minor unknown

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/7] drm/i915/psr: Nuke PSR support for VLV and CHV

== Series Details == Series: series starting with [v3,1/7] drm/i915/psr: Nuke PSR support for VLV and CHV URL : https://patchwork.freedesktop.org/series/43368/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4201_full -> Patchwork_9039_full = == Summary - FAILURE ==

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915: Move request->ctx aside

== Series Details == Series: series starting with [1/4] drm/i915: Move request->ctx aside URL : https://patchwork.freedesktop.org/series/43363/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4201_full -> Patchwork_9038_full = == Summary - WARNING == Minor unknown changes

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/19] drm/i915: Move request->ctx aside

== Series Details == Series: series starting with [01/19] drm/i915: Move request->ctx aside URL : https://patchwork.freedesktop.org/series/43307/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Move request->ctx aside Okay! Commit: drm/i915: Move fiddling with

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/19] drm/i915: Move request->ctx aside

== Series Details == Series: series starting with [01/19] drm/i915: Move request->ctx aside URL : https://patchwork.freedesktop.org/series/43307/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4195 -> Patchwork_9025 = == Summary - WARNING == Minor unknown changes coming

Re: [Intel-gfx] [PATCH] drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode

On Wed, 16 May 2018, Manasi Navare wrote: > This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp: > Do not do link training fallback or prune modes on EDP") that causes > a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) > where

Re: [Intel-gfx] [PATCH] drm/i915/oa: Check that OA is disabled before unpinning

This should be sent to stable right? - Lionel On 11/05/18 14:52, Chris Wilson wrote: Before we unpin the buffer used for OA reports and return it to the system, we need to be sure that the HW has finished writing into it. For lack of a better idea, poll OACONTROL to check it is switched off.

Re: [Intel-gfx] [PATCH v3 21/40] drm/i915: Define Intel HDCP2.2 registers

On Wednesday 09 May 2018 08:29 PM, Shankar, Uma wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] igt/gem_cpu_reloc: Check HW exists before attempting to use it (rev2)

== Series Details == Series: series starting with [1/3] igt/gem_cpu_reloc: Check HW exists before attempting to use it (rev2) URL : https://patchwork.freedesktop.org/series/43310/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4193 -> IGTPW_1372 = == Summary - WARNING ==

Re: [Intel-gfx] [PATCH 07/19] drm/i915/execlists: Handle copying default context state for atomic reset

On 17/05/2018 08:40, Chris Wilson wrote: We want to be able to reset the GPU from inside a timer callback (hardirq context). One step requires us to copy the default context state over to the guilty context, which means we need to plan in advance to have that object accessible from within an

Re: [Intel-gfx] [PATCH] Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."

On Thu, 17 May 2018, Jani Nikula wrote: > On Wed, 16 May 2018, Dhinakaran Pandiyan > wrote: >> On Wed, 2018-05-16 at 11:01 +0300, Jani Nikula wrote: >>> This reverts commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e. >>> >>> Per the report,

[Intel-gfx] [PATCH 11/19] drm/i915/execlists: Double check rpm wakeref

As we are splitting processing the CSB events from submitting the ELSP, we also need to duplicate the check that we hold a device wakeref for our hardware access to the disjoint locations. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 26

[Intel-gfx] [PATCH 14/19] drm/i915/execlists: Pull submit after dequeue under timeline lock

In the next patch, we will begin processing the CSB from inside the interrupt handler. This means that updating the execlists->port[] will no longer be locked by the tasklet but by the engine->timeline.lock instead. Pull dequeue and submit under the same lock for protection. (An alternative,

[Intel-gfx] [PATCH 04/19] drm/i915: Pull the context->pin_count dec into the common intel_context_unpin

As all backends implement the same pin_count mechanism and do a dec-and-test as their first step, pull that into the common intel_context_unpin(). This also pulls into the caller, eliminating the indirect call in the usual steady state case. The intel_context_pin() side is a little more

[Intel-gfx] [PATCH 19/19] drm/i915: Combine gt irq ack/handlers

Having abandoned the split approach of acking then handling the GT irqs (sacrificed to use the interrupt handler to guaranteed exclusive access to the irq data), pull the two routines into one to let the compiler eliminate the redundant storage. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 15/19] drm/i915/execlists: Process one CSB interrupt at a time

In the next patch, we will process the CSB events directly from the CS interrupt handler, being called for each interrupt. Hence, we will no longer have the need for a loop until the has-interrupt bit is clear, and in the meantime can remove that small optimisation. Signed-off-by: Chris Wilson

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

To ease the frequent and ugly pointer dance of >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

[Intel-gfx] [PATCH 07/19] drm/i915/execlists: Handle copying default context state for atomic reset

We want to be able to reset the GPU from inside a timer callback (hardirq context). One step requires us to copy the default context state over to the guilty context, which means we need to plan in advance to have that object accessible from within an atomic context. The atomic context prevents us

[Intel-gfx] [PATCH 06/19] drm/i915: Make intel_engine_dump irqsafe

To be useful later, enable intel_engine_dump() to be called from irq context (i.e. using saving and restoring irq start rather than assuming we enter with irqs enabled). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_engine_cs.c | 11 +++ 1 file

[Intel-gfx] [PATCH 09/19] drm/i915/execlists: HWACK checking superseded checking port[0].count

The HWACK bit more generically solves the problem of resubmitting ESLP while the hardware is still processing the current ELSP write. We no longer need to check port[0].count itself. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 2 -- 1 file

[Intel-gfx] [PATCH 08/19] 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 17/19] drm/i915/execlists: Process the CSB directly from inside the irq handler

As we now only use the cached HWSP access to read the CSB buffer and no longer use any forcewaked mmio, processing the CSB is fast and possible to do so directly from inside the CS interrupt handler. We have to rearrange the irq handler slightly as we wish to preserve the single threaded access

[Intel-gfx] [PATCH 01/19] 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

[Intel-gfx] [PATCH 18/19] drm/i915/execlists: Direct submission (avoid tasklet/ksoftirqd)

Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom half"), we came to the conclusion that running our CSB processing and ELSP submission from inside the irq handler was a bad idea. A really bad idea as we could impose nearly 1s latency on other users of the system, on

[Intel-gfx] [PATCH 13/19] drm/i915/execlists: Reset the CSB head tracking on reset/sanitization

We can avoid the mmio read of the CSB pointers after reset based on the knowledge that the HW always start writing at entry 0 in the CSB buffer. We need to reset our CSB head tracking after GPU reset (and on sanitization after resume) so that we are expecting to read from entry 0. Signed-off-by:

[Intel-gfx] [PATCH 10/19] drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler

Store whether or not we need to kick the guc's execlists emulation on the engine itself to avoid chasing the device info. gen8_cs_irq_handler 512 428 -84 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 4

[Intel-gfx] [PATCH 16/19] drm/i915/execlists: Unify CSB access pointers

Following the removal of the last workarounds, the only CSB mmio access is for the old vGPU interface. The mmio registers presented by vGPU do not require forcewake and can be treated as ordinary volatile memory, i.e. they behave just like the HWSP access just at a different location. We can

[Intel-gfx] [PATCH 05/19] 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/19] 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

[Intel-gfx] [PATCH 12/19] drm/i915: After reset on sanitization, reset the engine backends

As we reset the GPU on suspend/resume, we also do need to reset the engine state tracking so call into the engine backends. This is especially important so that we can also sanitize the state tracking across resume. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH v3 11/40] misc/mei/hdcp: Store the HDCP Pairing info

On Thu, 17 May 2018, "C, Ramalingam" wrote: >> > >> +/** >> > > Drop the extra *, unless you really love it :) >> > ha ha. Actually I have added intentionally. But removing them across >> > all patches as per your suggestions. :) >> >> /** is a syntax for KDoc, so if you

[Intel-gfx] [PATCH i-g-t 2/3] igt/gem_blits: Check for blitter support before use

Not all HW supports XY blitter commands, so check before use. Signed-off-by: Chris Wilson --- lib/i915/gem_submission.c | 16 lib/i915/gem_submission.h | 3 +++ tests/gem_linear_blits.c | 1 + tests/gem_tiled_blits.c | 1 +

[Intel-gfx] [PATCH i-g-t 3/3] igt/kms_frontbuffer_tracking: Skip over IGT_DRAW_BLT when there's no BLT

If the blitter is not available, we cannot use it as a source for dirty rectangles. We shall have to rely on the other engines to create GPU dirty instead. Signed-off-by: Chris Wilson --- tests/kms_frontbuffer_tracking.c | 2 ++ 1 file changed, 2 insertions(+) diff

[Intel-gfx] [PATCH i-g-t 1/3] igt/gem_cpu_reloc: Check HW exists before attempting to use it

Confirm we have the available HW before asserting it succeeds. Signed-off-by: Chris Wilson --- tests/gem_cpu_reloc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/gem_cpu_reloc.c b/tests/gem_cpu_reloc.c index 882c312d4..e3bbcd239 100644 ---

Re: [Intel-gfx] [PATCH] drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

On Wed, 16 May 2018, Dhinakaran Pandiyan wrote: > On Wed, 2018-05-16 at 09:33 -0700, matthew.s.atw...@intel.com wrote: >> From: Matt Atwood >> >> According to DP spec (2.9.3.1 of DP 1.4) if >> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

Re: [Intel-gfx] [PATCH 05/19] drm/i915: Be irqsafe inside reset

On 17/05/2018 08:40, Chris Wilson wrote: As we want to be able to call i915_reset_engine and co from a softirq or Just by glancing i915_reset_engine looks to heavy weight to ever be callable from softirq/timer context. There is even a flush_workqueue in there. timer context, we need to

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/19] drm/i915: Move request->ctx aside

== Series Details == Series: series starting with [01/19] drm/i915: Move request->ctx aside URL : https://patchwork.freedesktop.org/series/43307/ State : warning == Summary == $ dim checkpatch origin/drm-tip 61b8422e1e2d drm/i915: Move request->ctx aside 2bb24771dc50 drm/i915: Move fiddling

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

On Wed, 16 May 2018, Dhinakaran Pandiyan wrote: > On Wed, 2018-05-16 at 11:08 +0300, Jani Nikula wrote: >> I think the patch is now the way it should be. We should not change >> our interpretation based on the value. > > Is it correct to infer, from your response,

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, Nothing too big this time either, a missing W/A added and fix for rare HW race in addition to early IOCTL error check. We got kthread_park related splats to CI from -rc5, so the results are to be taken with a pinch of salt. The fix to factor around it is bit too much for -fixes and

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Wait longer for the old active request

== Series Details == Series: drm/i915/selftests: Wait longer for the old active request URL : https://patchwork.freedesktop.org/series/43315/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4196 -> Patchwork_9026 = == Summary - SUCCESS == No regressions found. External

Re: [Intel-gfx] [PATCH] dim: replace pipe commands with single sed

On Sat, 12 May 2018, Daniel Vetter wrote: > On Wed, May 09, 2018 at 04:32:53PM -0700, Lucas De Marchi wrote: >> Now CC the right mailing list. The way dim sets up the repository you >> can't have individual git configs, e.g. to set a different >> sendemail.to for dim-tools :(

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] igt/gem_cpu_reloc: Check HW exists before attempting to use it

== Series Details == Series: series starting with [1/3] igt/gem_cpu_reloc: Check HW exists before attempting to use it URL : https://patchwork.freedesktop.org/series/43310/ State : failure == Summary == IGT patchset build failed on latest successful build

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Clean up ADPA pipe select bits

On Mon, 14 May 2018, Ville Syrjala wrote: > From: Ville Syrjälä > > Clean up the ADPA pipe select bits. To make the whole situation a bit > less ugly we'll start to share the same code between .get_hw_state() > and the port state

Re: [Intel-gfx] [PATCH] drm/i915/oa: Check that OA is disabled before unpinning

Quoting Lionel Landwerlin (2018-05-17 11:18:16) > This should be sent to stable right? Yeah, my bad for not digging out the relevant Fixes: +cc Joonas for the next batch. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 04/19] drm/i915: Pull the context->pin_count dec into the common intel_context_unpin

Quoting Tvrtko Ursulin (2018-05-17 11:20:22) > > On 17/05/2018 08:40, Chris Wilson wrote: > > As all backends implement the same pin_count mechanism and do a > > dec-and-test as their first step, pull that into the common > > intel_context_unpin(). This also pulls into the caller, eliminating the

Re: [Intel-gfx] [PATCH v11 0/2] Enabling content-type setting for HDMI displays.

Ping.. On Tue, 2018-05-15 at 16:59 +0300, StanLis wrote: > From: Stanislav Lisovskiy > > Added content type setting property to drm_connector(part 1) > and enabled transmitting it with HDMI AVI infoframes > for i915(part 2). > > Stanislav Lisovskiy (2): > drm:

[Intel-gfx] [PATCH] drm/i915/selftests: Wait longer for the old active request

When testing reset, we wait for 1s on the main thread for the hang to start. Meanwhile, we continue submitting requests on all the background threads, and we may have more threads than cores and so potentially starve the waiter from being woken within the timeout. As the hang timeout and the

[Intel-gfx] [PATCH i-g-t] igt/kms_frontbuffer_tracking: Skip over IGT_DRAW_BLT when there's no BLT

If the blitter is not available, we cannot use it as a source for dirty rectangles. We shall have to rely on the other engines to create GPU dirty instead. v2: Try using lots of subgroup+fixtures Signed-off-by: Chris Wilson --- tests/kms_frontbuffer_tracking.c | 58

Re: [Intel-gfx] [PATCH 04/19] drm/i915: Pull the context->pin_count dec into the common intel_context_unpin

On 17/05/2018 08:40, Chris Wilson wrote: As all backends implement the same pin_count mechanism and do a dec-and-test as their first step, pull that into the common intel_context_unpin(). This also pulls into the caller, eliminating the indirect call in the usual steady state case. The

Re: [Intel-gfx] [PATCH] Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP"

On Wed, 16 May 2018, Lucas De Marchi wrote: > This reverts commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677. > > This fails on a Dell XPS13 9350 machine giving me just a black screen. > [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training > Passed

Re: [Intel-gfx] [PATCH] Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."

On Wed, 16 May 2018, Dhinakaran Pandiyan wrote: > On Wed, 2018-05-16 at 11:01 +0300, Jani Nikula wrote: >> This reverts commit dc911f5bd8aacfcf8aabd5c26c88e04c837a938e. >> >> Per the report, no matter what display mode you select with xrandr, >> the >> i915 driver

[Intel-gfx] [drm-intel:topic/core-for-CI 6/9] htmldocs: kernel/kthread.c:377: warning: Function parameter or member 'exited_key' not described in '_kthread_create_on_node'

Hi Daniel, First bad commit (maybe != root cause): tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI head: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6 commit: 64b3f927aacc356dd742b3a83aead21fba7e56dd [6/9] lockdep: finer-grained completion key for kthread reproduce: make htmldocs

Re: [Intel-gfx] [PATCH] Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP"

On Wed, 16 May 2018, Manasi Navare wrote: > On Wed, May 16, 2018 at 10:21:10AM -0700, Lucas De Marchi wrote: >> This reverts commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677. >> >> This fails on a Dell XPS13 9350 machine giving me just a black screen. >>

Re: [Intel-gfx] [PATCH] drm/i915/oa: Check that OA is disabled before unpinning

On 17/05/18 11:21, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-05-17 11:18:16) This should be sent to stable right? Yeah, my bad for not digging out the relevant Fixes: +cc Joonas for the next batch. -Chris I should have looked at it too. Was just in shock ;) For Haswell: Fixes:

Re: [Intel-gfx] [PATCH 06/19] drm/i915: Make intel_engine_dump irqsafe

On 17/05/2018 08:40, Chris Wilson wrote: To be useful later, enable intel_engine_dump() to be called from irq context (i.e. using saving and restoring irq start rather than assuming we enter with irqs enabled). Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH v3 22/40] drm/i915: Wrappers for mei HDCP2.2 services

On Wednesday 09 May 2018 08:40 PM, Shankar, Uma wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH 10/19] drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler

On 17/05/2018 08:40, Chris Wilson wrote: Store whether or not we need to kick the guc's execlists emulation on the engine itself to avoid chasing the device info. We do not chase device info but modparams in this case. gen8_cs_irq_handler 512 428 -84 I

Re: [Intel-gfx] [PATCH 10/19] drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler

On 17/05/2018 12:24, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-17 11:58:21) On 17/05/2018 08:40, Chris Wilson wrote: Store whether or not we need to kick the guc's execlists emulation on the engine itself to avoid chasing the device info. We do not chase device info but modparams

Re: [Intel-gfx] [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption

On Thursday 17 May 2018 06:31 PM, Ramalingam C wrote: On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To:

Re: [Intel-gfx] [PATCH 09/19] drm/i915/execlists: HWACK checking superseded checking port[0].count

On 17/05/2018 08:40, Chris Wilson wrote: The HWACK bit more generically solves the problem of resubmitting ESLP while the hardware is still processing the current ELSP write. We no longer need to check port[0].count itself. Signed-off-by: Chris Wilson ---

[Intel-gfx] Query about INTEL modifiers referred in intel_display.c

Hi, I was going through drivers/gpu/drm/i915/intel_display.c to get an understanding about how framebuffer modifiers are used in the drm subsystem. I could see the following in intel_framebuffer_init(), (added in commit 2e2adb0573) << some code >> switch (mode_cmd->modifier[0]) { case

Re: [Intel-gfx] [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater authentication

On Monday 14 May 2018 02:38 PM, Shankar, Uma wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH 18/19] drm/i915/execlists: Direct submission (avoid tasklet/ksoftirqd)

On 17/05/2018 08:40, Chris Wilson wrote: Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom half"), we came to the conclusion that running our CSB processing and ELSP submission from inside the irq handler was a bad idea. A really bad idea as we could impose nearly

Re: [Intel-gfx] [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able

On Monday 14 May 2018 03:00 PM, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH 08/19] drm/i915: Allow init_breadcrumbs to be used from irq context

On 17/05/2018 08:40, Chris Wilson wrote: 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 ---

Re: [Intel-gfx] Query about INTEL modifiers referred in intel_display.c

On Thu, May 17, 2018 at 11:55:47AM +0100, Ayan Halder wrote: > Hi, > > I was going through drivers/gpu/drm/i915/intel_display.c to get an > understanding about how framebuffer modifiers are used in the drm > subsystem. > I could see the following in intel_framebuffer_init(), > (added in commit

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Use offsetofend() rather than offsetof + sizeof

On 2018.05.16 17:38:30 +0100, Chris Wilson wrote: > Quoting Mika Kuoppala (2017-03-16 09:37:44) > > Chris Wilson writes: > > > > > Compute the offset of the end of the crc32 field using offsetofend() > > > rather than open-coding. > > > > > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 05/19] drm/i915: Be irqsafe inside reset

Quoting Tvrtko Ursulin (2018-05-17 11:27:20) > > On 17/05/2018 08:40, Chris Wilson wrote: > > As we want to be able to call i915_reset_engine and co from a softirq or > > Just by glancing i915_reset_engine looks to heavy weight to ever be > callable from softirq/timer context. There is even a

Re: [Intel-gfx] [PATCH 10/19] drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler

Quoting Tvrtko Ursulin (2018-05-17 11:58:21) > > On 17/05/2018 08:40, Chris Wilson wrote: > > Store whether or not we need to kick the guc's execlists emulation on > > the engine itself to avoid chasing the device info. > > We do not chase device info but modparams in this case. > > >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Wait longer for the old active request

== Series Details == Series: drm/i915/selftests: Wait longer for the old active request URL : https://patchwork.freedesktop.org/series/43315/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4196_full -> Patchwork_9026_full = == Summary - WARNING == Minor unknown changes

Re: [Intel-gfx] [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption

On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check

On Monday 14 May 2018 03:15 PM, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] igt/gem_cpu_reloc: Check HW exists before attempting to use it (rev2)

== Series Details == Series: series starting with [1/3] igt/gem_cpu_reloc: Check HW exists before attempting to use it (rev2) URL : https://patchwork.freedesktop.org/series/43310/ State : success == Summary == = CI Bug Log - changes from IGT_4485_full -> IGTPW_1372_full = == Summary -

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/19] drm/i915: Move request->ctx aside

== Series Details == Series: series starting with [01/19] drm/i915: Move request->ctx aside URL : https://patchwork.freedesktop.org/series/43307/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4195_full -> Patchwork_9025_full = == Summary - FAILURE == Serious unknown

Re: [Intel-gfx] [PATCH 11/19] drm/i915/execlists: Double check rpm wakeref

On 17/05/2018 08:40, Chris Wilson wrote: As we are splitting processing the CSB events from submitting the ELSP, we also need to duplicate the check that we hold a device wakeref for our hardware access to the disjoint locations. Signed-off-by: Chris Wilson ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/execlists: HWACK checking superseded checking port[0].count

== Series Details == Series: drm/i915/execlists: HWACK checking superseded checking port[0].count URL : https://patchwork.freedesktop.org/series/43322/ State : warning == Summary == $ dim checkpatch origin/drm-tip bbad01ba6ca9 drm/i915/execlists: HWACK checking superseded checking

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: HWACK checking superseded checking port[0].count

== Series Details == Series: drm/i915/execlists: HWACK checking superseded checking port[0].count URL : https://patchwork.freedesktop.org/series/43322/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4196 -> Patchwork_9027 = == Summary - WARNING == Minor unknown changes

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer

Hi Ville, On 23 March 2018 at 14:49, Daniel Stone wrote: > On 23 March 2018 at 14:42, Ville Syrjälä > wrote: >> Hmm. I'm thinking we can stick to the single reference per fb. >> IIRC this counter is there just to prevent changes of the obj

[Intel-gfx] [PATCH] drm/i915/icl: Don't update enabled dbuf slices struct until updated in hw

Do not update number of enabled dbuf slices in dev_priv struct until we actually enable/disable dbuf slice in hw. This is leading to never updating dbuf slices and resulting in DBuf slice mismatch warning. Fixes: aa9664ffe863 ("drm/i915/icl: Enable 2nd DBuf slice only when needed") Signed-off-by:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Don't update enabled dbuf slices struct until updated in hw

== Series Details == Series: drm/i915/icl: Don't update enabled dbuf slices struct until updated in hw URL : https://patchwork.freedesktop.org/series/43330/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4196 -> Patchwork_9028 = == Summary - SUCCESS == No regressions

[Intel-gfx] [CI] drm/i915/execlists: HWACK checking superseded checking port[0].count

The HWACK bit more generically solves the problem of resubmitting ESLP while the hardware is still processing the current ELSP write. We no longer need to check port[0].count itself. References: ba74cb10c775 ("drm/i915/execlists: Delay writing to ELSP until HW has processed the previous write")

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Wait longer for the old active request

When testing reset, we wait for 1s on the main thread for the hang to start. Meanwhile, we continue submitting requests on all the background threads, and we may have more threads than cores and so potentially starve the waiter from being woken within the timeout. As the hang timeout and the

[Intel-gfx] [PATCH] drm/i915: Nul-terminate legacy debug string

Make sure that when we don't have any scheduler attributes for the request the string is terminated. Fixes: 247870ac8ea7 ("drm/i915: Build request info on stack before printk") Signed-off-by: Chris Wilson Cc: Joonas Lahtinen ---

Re: [Intel-gfx] [PATCH] drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

On Thu, 2018-05-17 at 12:50 +0300, Jani Nikula wrote: > On Wed, 16 May 2018, Dhinakaran Pandiyan om> wrote: > > On Wed, 2018-05-16 at 09:33 -0700, matthew.s.atw...@intel.com > > wrote: > > > From: Matt Atwood > > > > > > According to DP

[Intel-gfx] [PATCH 2/2] drm/i915: Flush the RING stop bit after clearing RING_HEAD in reset

Inside the live_hangcheck (reset) selftests, we occasionally see failures like <7>[ 239.094840] i915_gem_set_wedged rcs0 <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a, hangcheck 0 [5158 ms] <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) <7>[

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftests: Wait longer for the old active request

== Series Details == Series: series starting with [1/2] drm/i915/selftests: Wait longer for the old active request URL : https://patchwork.freedesktop.org/series/43334/ State : warning == Summary == $ dim checkpatch origin/drm-tip ddf6fd832a10 drm/i915/selftests: Wait longer for the old

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Wait longer for the old active request

When testing reset, we wait for 1s on the main thread for the hang to start. Meanwhile, we continue submitting requests on all the background threads, and we may have more threads than cores and so potentially starve the waiter from being woken within the timeout. As the hang timeout and the

[Intel-gfx] [PATCH 2/2] drm/i915: Flush the RING stop bit after clearing RING_HEAD in reset

Inside the live_hangcheck (reset) selftests, we occasionally see failures like <7>[ 239.094840] i915_gem_set_wedged rcs0 <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a, hangcheck 0 [5158 ms] <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) <7>[

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Nul-terminate legacy debug string

== Series Details == Series: drm/i915: Nul-terminate legacy debug string URL : https://patchwork.freedesktop.org/series/43341/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4197 -> Patchwork_9031 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] [PATCH] drm/i915: Remove unused enable_cmd_parser modparam

The command parser is feature complete, stable and required by userspace. In commit 41736a8e3331 ("drm/i915: Use the precomputed value for whether to enable command parsing") I accidentally removed control from the modparam, and as no one has complained, eemove the left over modparam completely!

Re: [Intel-gfx] [PATCH i-g-t 1/3] igt/gem_cpu_reloc: Check HW exists before attempting to use it

On 17/05/18 01:23, Chris Wilson wrote: Confirm we have the available HW before asserting it succeeds. Signed-off-by: Chris Wilson --- tests/gem_cpu_reloc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/gem_cpu_reloc.c b/tests/gem_cpu_reloc.c index

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/selftests: Wait longer for the old active request

== Series Details == Series: series starting with [1/2] drm/i915/selftests: Wait longer for the old active request URL : https://patchwork.freedesktop.org/series/43334/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4197 -> Patchwork_9029 = == Summary - FAILURE ==

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Remove unused enable_cmd_parser modparam

== Series Details == Series: drm/i915: Remove unused enable_cmd_parser modparam URL : https://patchwork.freedesktop.org/series/43340/ State : warning == Summary == $ dim checkpatch origin/drm-tip 913921ed0c35 drm/i915: Remove unused enable_cmd_parser modparam -:12:

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/selftests: Wait longer for the old active request

== Series Details == Series: series starting with [1/2] drm/i915/selftests: Wait longer for the old active request URL : https://patchwork.freedesktop.org/series/43334/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4197 -> Patchwork_9032 = == Summary - FAILURE ==

Re: [Intel-gfx] [PATCH] drm/i915: Remove unused enable_cmd_parser modparam

On Thu, 17 May 2018, Chris Wilson wrote: > The command parser is feature complete, stable and required by > userspace. In commit 41736a8e3331 ("drm/i915: Use the precomputed value > for whether to enable command parsing") I accidentally removed control > from the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove unused enable_cmd_parser modparam

== Series Details == Series: drm/i915: Remove unused enable_cmd_parser modparam URL : https://patchwork.freedesktop.org/series/43340/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4197 -> Patchwork_9030 = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: HWACK checking superseded checking port[0].count

== Series Details == Series: drm/i915/execlists: HWACK checking superseded checking port[0].count URL : https://patchwork.freedesktop.org/series/43322/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4196_full -> Patchwork_9027_full = == Summary - WARNING == Minor unknown

Re: [Intel-gfx] [PATCH v11 0/2] Enabling content-type setting for HDMI displays.

On Tue, May 15, 2018 at 04:59:26PM +0300, StanLis wrote: > From: Stanislav Lisovskiy > > Added content type setting property to drm_connector(part 1) > and enabled transmitting it with HDMI AVI infoframes > for i915(part 2). > > Stanislav Lisovskiy (2): > drm:

Re: [Intel-gfx] [PATCH i-g-t 1/3] igt/gem_cpu_reloc: Check HW exists before attempting to use it

Quoting Antonio Argenziano (2018-05-17 16:08:14) > > > On 17/05/18 01:23, Chris Wilson wrote: > > Confirm we have the available HW before asserting it succeeds. > > > > Signed-off-by: Chris Wilson > > --- > > tests/gem_cpu_reloc.c | 1 + > > 1 file changed, 1

  1   2   3   >