[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt:fix raw-wakeref not held calltrace in vGPU

== Series Details == Series: drm/i915/gt:fix raw-wakeref not held calltrace in vGPU URL : https://patchwork.freedesktop.org/series/80497/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8867_full -> Patchwork_18340_full Summa

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/kbl: Fix revision ID checks (rev2)

== Series Details == Series: drm/i915/kbl: Fix revision ID checks (rev2) URL : https://patchwork.freedesktop.org/series/80419/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8867_full -> Patchwork_18339_full Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt:fix raw-wakeref not held calltrace in vGPU

== Series Details == Series: drm/i915/gt:fix raw-wakeref not held calltrace in vGPU URL : https://patchwork.freedesktop.org/series/80497/ State : success == Summary == CI Bug Log - changes from CI_DRM_8867 -> Patchwork_18340 Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt:fix raw-wakeref not held calltrace in vGPU

== Series Details == Series: drm/i915/gt:fix raw-wakeref not held calltrace in vGPU URL : https://patchwork.freedesktop.org/series/80497/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. _

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/kbl: Fix revision ID checks (rev2)

== Series Details == Series: drm/i915/kbl: Fix revision ID checks (rev2) URL : https://patchwork.freedesktop.org/series/80419/ State : success == Summary == CI Bug Log - changes from CI_DRM_8867 -> Patchwork_18339 Summary --- **SUCCE

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to check max stride for disabled/non-existent display

On Mon, Aug 10, 2020 at 09:53:44PM +0100, Chris Wilson wrote: > Quoting Matt Roper (2020-08-10 19:08:51) > > Userspace may still create GEM dumb buffers even on platforms with > > disabled or non-existent display. When creating dumb buffers we try to > > check the max fb stride for the platform by

[Intel-gfx] [PATCH] drm/i915/gt:fix raw-wakeref not held calltrace in vGPU

UNCORE_HAS_FORCEWAKE is not turned on when intel_vgpu_active() returns true, so the guest mmio writes go to gen2_write32(). [ cut here ] RPM raw-wakeref not held WARNING: CPU: 1 PID: 6375 at drivers/gpu/drm/i915/intel_runtime_pm.h:106 gen2_write32+0x10b/0x140 [i915] Mo

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/kbl: Fix revision ID checks (rev2)

== Series Details == Series: drm/i915/kbl: Fix revision ID checks (rev2) URL : https://patchwork.freedesktop.org/series/80419/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/kbl: Fix revision ID checks (rev2)

== Series Details == Series: drm/i915/kbl: Fix revision ID checks (rev2) URL : https://patchwork.freedesktop.org/series/80419/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2734daf22ac5 drm/i915/kbl: Fix revision ID checks -:143: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev

Re: [Intel-gfx] [RFC 00/60] DG1 LMEM enabling

Hi Matthew, do you have a rebase of these or a git tree with them, once I hit the PPGTT support applying started to get messy. Dave. On Fri, 10 Jul 2020 at 21:58, Matthew Auld wrote: > > This is Lucas' DG1 enabling series[1], plus some of the DG1 specific enablers > for supporting LMEM on top,

[Intel-gfx] [PATCH v2] drm/i915/kbl: Fix revision ID checks

We usually assume that increasing PCI device revision ID's translates to newer steppings; macros like IS_KBL_REVID() that we use rely on this behavior. Unfortunately this turns out to not be true on KBL; the newer device 2 revision ID's sometimes go backward to older steppings. The situation is fu

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch (rev2)

== Series Details == Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch (rev2) URL : https://patchwork.freedesktop.org/series/80478/ State : success == Summary == CI Bug Log - changes from CI_DRM_8866_full -> Patchwork_18337_full ===

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/kmb: Add support for KeemBay Display (rev4)

== Series Details == Series: drm/kmb: Add support for KeemBay Display (rev4) URL : https://patchwork.freedesktop.org/series/79615/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8866_full -> Patchwork_18336_full Summary

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Update to GuC v45.0.0

On 8/7/2020 10:46 AM, john.c.harri...@intel.com wrote: From: John Harrison Update to the latest GuC firmware. This includes some significant changes to the interface. A high level overview of the changes would be nice for extra clarity. A couple of example: - GuC now requires a private m

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v6,01/11] HAX to make DSC work on the icelake test system (rev3)

== Series Details == Series: series starting with [v6,01/11] HAX to make DSC work on the icelake test system (rev3) URL : https://patchwork.freedesktop.org/series/79534/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8866 -> Patchwork_18338

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v6,01/11] HAX to make DSC work on the icelake test system (rev3)

== Series Details == Series: series starting with [v6,01/11] HAX to make DSC work on the icelake test system (rev3) URL : https://patchwork.freedesktop.org/series/79534/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't b

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v6,01/11] HAX to make DSC work on the icelake test system (rev3)

== Series Details == Series: series starting with [v6,01/11] HAX to make DSC work on the icelake test system (rev3) URL : https://patchwork.freedesktop.org/series/79534/ State : warning == Summary == $ dim checkpatch origin/drm-tip 94f4928909c8 HAX to make DSC work on the icelake test system

[Intel-gfx] [PATCH v8 06/11] drm/i915: Enable big joiner support in enable and disable sequences.

From: Maarten Lankhorst Make vdsc work when no output is enabled. The big joiner needs VDSC on the slave, so enable it and set the appropriate bits. Also update timestamping constants, because slave crtc's are not updated in drm_atomic_helper_update_legacy_modeset_state(). This should be enough

Re: [Intel-gfx] [PATCH v6 06/11] drm/i915: Enable big joiner support in enable and disable sequences.

On Mon, Aug 10, 2020 at 02:45:52PM +0200, Maarten Lankhorst wrote: > Op 16-07-2020 om 21:27 schreef Manasi Navare: > > On Wed, Jul 15, 2020 at 03:42:17PM -0700, Manasi Navare wrote: > >> From: Maarten Lankhorst > >> > >> Make vdsc work when no output is enabled. The big joiner needs VDSC > >> on t

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch (rev2)

== Series Details == Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch (rev2) URL : https://patchwork.freedesktop.org/series/80478/ State : success == Summary == CI Bug Log - changes from CI_DRM_8866 -> Patchwork_18337 =

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch (rev2)

== Series Details == Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch (rev2) URL : https://patchwork.freedesktop.org/series/80478/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch (rev2)

== Series Details == Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch (rev2) URL : https://patchwork.freedesktop.org/series/80478/ State : warning == Summary == $ dim checkpatch origin/drm-tip bc91a045ae56 drm/i915: Initial implementation of PSR2

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/kmb: Add support for KeemBay Display (rev4)

== Series Details == Series: drm/kmb: Add support for KeemBay Display (rev4) URL : https://patchwork.freedesktop.org/series/79615/ State : success == Summary == CI Bug Log - changes from CI_DRM_8866 -> Patchwork_18336 Summary --- **S

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/kmb: Add support for KeemBay Display (rev4)

== Series Details == Series: drm/kmb: Add support for KeemBay Display (rev4) URL : https://patchwork.freedesktop.org/series/79615/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7aaa226cd61c drm/kmb: Add support for KeemBay Display -:58: WARNING:FILE_PATH_CHANGES: added, moved o

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Don't try to check max stride for disabled/non-existent display

== Series Details == Series: drm/i915: Don't try to check max stride for disabled/non-existent display URL : https://patchwork.freedesktop.org/series/80479/ State : success == Summary == CI Bug Log - changes from CI_DRM_8866_full -> Patchwork_18335_full ===

[Intel-gfx] [PATCH v6] Add support for KeemBay DRM driver

This is a new DRM driver for Intel's KeemBay SOC. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This driver is tested with the KMB EVM board which is the refernce baord for Keem Bay SOC. The SOC's display pipeline is as follows +--++-++-

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to check max stride for disabled/non-existent display

Quoting Matt Roper (2020-08-10 19:08:51) > Userspace may still create GEM dumb buffers even on platforms with > disabled or non-existent display. When creating dumb buffers we try to > check the max fb stride for the platform by looking at the first pipe on > the platform. We previously fixed a c

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch

== Series Details == Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch URL : https://patchwork.freedesktop.org/series/80478/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8865_full -> Patchwork_18334_full ==

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't try to check max stride for disabled/non-existent display

== Series Details == Series: drm/i915: Don't try to check max stride for disabled/non-existent display URL : https://patchwork.freedesktop.org/series/80479/ State : success == Summary == CI Bug Log - changes from CI_DRM_8866 -> Patchwork_18335 =

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Don't try to check max stride for disabled/non-existent display

== Series Details == Series: drm/i915: Don't try to check max stride for disabled/non-existent display URL : https://patchwork.freedesktop.org/series/80479/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked sep

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch

== Series Details == Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch URL : https://patchwork.freedesktop.org/series/80478/ State : success == Summary == CI Bug Log - changes from CI_DRM_8865 -> Patchwork_18334

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Fix NV12 sub plane atomic state

== Series Details == Series: drm/i915/display: Fix NV12 sub plane atomic state URL : https://patchwork.freedesktop.org/series/80474/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8864_full -> Patchwork_18332_full Summary --

[Intel-gfx] [PATCH] drm/i915: Don't try to check max stride for disabled/non-existent display

Userspace may still create GEM dumb buffers even on platforms with disabled or non-existent display. When creating dumb buffers we try to check the max fb stride for the platform by looking at the first pipe on the platform. We previously fixed a crash related to accessing the non-existent PIPE_A

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch

== Series Details == Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch URL : https://patchwork.freedesktop.org/series/80478/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't b

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch

== Series Details == Series: series starting with [CI,1/2] drm/i915: Initial implementation of PSR2 selective fetch URL : https://patchwork.freedesktop.org/series/80478/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2802a6d0b15e drm/i915: Initial implementation of PSR2 selecti

Re: [Intel-gfx] [PATCH 07/24] drm/i915: Parse command buffer earlier in eb_relocate(slow)

On 8/10/20 12:30 PM, Maarten Lankhorst wrote: We want to introduce backoff logic, but we need to lock the pool object as well for command parsing. Because of this, we will need backoff logic for the engine pool obj, move the batch validation up slightly to eb_lookup_vmas, and the actual command

Re: [Intel-gfx] [PATCH 06/24] drm/i915: Remove locking from i915_gem_object_prepare_read/write

On 8/10/20 12:30 PM, Maarten Lankhorst wrote: Execbuffer submission will perform its own WW locking, and we cannot rely on the implicit lock there. This also makes it clear that the GVT code will get a lockdep splat when multiple batchbuffer shadows need to be performed in the same instance, fi

[Intel-gfx] [PATCH CI 2/2] drm/i915/display: Implement WA 1408330847

From the 3 WAs for PSR2 man track/selective fetch this is only one needed when doing single full frames at every flip. Reviewed-by: Gwan-gyeong Mun Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_psr.c | 19 +-- drivers/gpu/drm/i915/i915_reg.h

[Intel-gfx] [PATCH CI 1/2] drm/i915: Initial implementation of PSR2 selective fetch

All GEN12 platforms supports PSR2 selective fetch but not all GEN12 platforms supports PSR2 hardware tracking(aka RKL). This feature consists in software programming registers with the damaged area of each plane this way hardware will only fetch from memory those areas and sent the PSR2 selective

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/2] drm/i915/tgl: Set subplatforms

On Sat, 2020-08-08 at 02:15 +, Patchwork wrote: > Patch Details > Series: series starting with [CI,1/2] drm/i915/tgl: Set subplatforms > URL: https://patchwork.freedesktop.org/series/80404/ > State:failure > Details: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_1832

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock

== Series Details == Series: drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock URL : https://patchwork.freedesktop.org/series/80475/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8864 -> Patchwork_18333 ===

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock

== Series Details == Series: drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock URL : https://patchwork.freedesktop.org/series/80475/ State : warning == Summary == $ dim checkpatch origin/drm-tip 89b5186bbf39 drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP shar

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock

== Series Details == Series: drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock URL : https://patchwork.freedesktop.org/series/80475/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separ

[Intel-gfx] [PATCH] drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a clock

We assume that both timestamps are driven off the same clock [reported to userspace as I915_PARAM_CS_TIMESTAMP_FREQUENCY]. Verify that this is so by reading the timestamp registers around a busywait (on an otherwise engine so there should be no preemptions). Signed-off-by: Chris Wilson --- drive

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix NV12 sub plane atomic state

== Series Details == Series: drm/i915/display: Fix NV12 sub plane atomic state URL : https://patchwork.freedesktop.org/series/80474/ State : success == Summary == CI Bug Log - changes from CI_DRM_8864 -> Patchwork_18332 Summary --- *

[Intel-gfx] [PATCH 1/1] dummy empty commit

Trying to ensure that patchwork no longer sees the commit this is replied to. --- drivers/gpu/drm/i915/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index bda4c0e408f8..f6f3fc651086 100644 --- a/drivers/gpu/drm/i915/Makef

Re: [Intel-gfx] [PATCH] drm/i915/display: Fix NV12 sub plane atomic state

> -Original Message- > From: Maarten Lankhorst > Sent: Monday, August 10, 2020 8:17 PM > To: Shankar, Uma ; intel-gfx@lists.freedesktop.org > Cc: Zuo, Alex ; Kumar, Abhishek4 > ; sta...@vger.kernel.org > Subject: Re: [PATCH] drm/i915/display: Fix NV12 sub plane atomic state > > Op 10-0

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/display: Implement WA 1408330847

On Mon, 2020-07-06 at 16:43 -0700, José Roberto de Souza wrote: > From the 3 WAs for PSR2 man track/selective fetch this is only one > needed when doing single full frames at every flip. > > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/display/intel_psr.c | 19 ++

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Initial implementation of PSR2 selective fetch

On Mon, 2020-07-06 at 16:43 -0700, José Roberto de Souza wrote: > All GEN12 platforms supports PSR2 selective fetch but not all GEN12 > platforms supports PSR2 hardware tracking(aka RKL). > > This feature consists in software programming registers with the > damaged area of each plane this way har

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: Fix NV12 sub plane atomic state

== Series Details == Series: drm/i915/display: Fix NV12 sub plane atomic state URL : https://patchwork.freedesktop.org/series/80474/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. __

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Fix NV12 sub plane atomic state

== Series Details == Series: drm/i915/display: Fix NV12 sub plane atomic state URL : https://patchwork.freedesktop.org/series/80474/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1cf8e8b47de4 drm/i915/display: Fix NV12 sub plane atomic state -:14: ERROR:GERRIT_CHANGE_ID: Remove

Re: [Intel-gfx] [PATCH] drm/i915/display: Fix NV12 sub plane atomic state

Op 10-08-2020 om 17:16 schreef Uma Shankar: > From: Abhishek Kumar > > For NV12 display sub plane is also configured and drivers internally > create plane atomic state. Driver copies all of the param of main > plane atomic state to sub planer atomic state but in sub plane > atomic state crtc is no

[Intel-gfx] [PATCH] drm/i915/display: Fix NV12 sub plane atomic state

From: Abhishek Kumar For NV12 display sub plane is also configured and drivers internally create plane atomic state. Driver copies all of the param of main plane atomic state to sub planer atomic state but in sub plane atomic state crtc is not added ,so when drm atomic state is configured for com

[Intel-gfx] [PATCH 1/1] dummy empty commit

--- drivers/gpu/drm/i915/dummy.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 drivers/gpu/drm/i915/dummy.c diff --git a/drivers/gpu/drm/i915/dummy.c b/drivers/gpu/drm/i915/dummy.c new file mode 100644 index ..e69de29bb2d1 -- 2.28.0 ___

Re: [Intel-gfx] [PATCH] dma-buf.rst: repair length of title underline

Am 09.08.20 um 08:17 schrieb Lukas Bulwahn: With commit 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are a bad idea"), document generation warns: Documentation/driver-api/dma-buf.rst:182: \ WARNING: Title underline too short. Repair length of title underline to remove warnin

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/vlv_dsi_pll: fix spelling mistake "Cant" -> "Can't"

== Series Details == Series: drm/i915/vlv_dsi_pll: fix spelling mistake "Cant" -> "Can't" URL : https://patchwork.freedesktop.org/series/80463/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8862_full -> Patchwork_18330_full

Re: [Intel-gfx] [PATCH] dma-buf.rst: repair length of title underline

On Mon, Aug 10, 2020 at 01:25:40PM +0200, Christian König wrote: > Am 09.08.20 um 08:17 schrieb Lukas Bulwahn: > > With commit 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are > > a bad idea"), document generation warns: > > > >Documentation/driver-api/dma-buf.rst:182: \ > >W

Re: [Intel-gfx] [PATCH 09/24] drm/i915: make lockdep slightly happier about execbuf.

Op 10-08-2020 om 12:30 schreef Maarten Lankhorst: > As soon as we install fences, we should stop allocating memory > in order to prevent any potential deadlocks. > > This is required later on, when we start adding support for > dma-fence annotations, and also required for userptr. This patch causes

Re: [Intel-gfx] [PATCH v6 11/11] drm/i915: Add debugfs dumping for bigjoiner, v3.

Op 16-07-2020 om 00:42 schreef Manasi Navare: > From: Maarten Lankhorst > > Dump debugfs and planar links as well, this will make it easier to debug > when things go wrong. > > v4: > * Rebase > Changes since v1: > - Report planar slaves as such, now that we have the plane_state switch. > Changes s

Re: [Intel-gfx] [PATCH v6 06/11] drm/i915: Enable big joiner support in enable and disable sequences.

Op 16-07-2020 om 21:27 schreef Manasi Navare: > On Wed, Jul 15, 2020 at 03:42:17PM -0700, Manasi Navare wrote: >> From: Maarten Lankhorst >> >> Make vdsc work when no output is enabled. The big joiner needs VDSC >> on the slave, so enable it and set the appropriate bits. >> Also update timestampin

[Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Emit a semaphore to measure

Don't assume the kernel will emit a semaphore to synchronise between two engine, and emit the semaphore ourselves for the basis of our measurements. The purpose of the test is to try and ascertain the accuracy of the two sampling methods, semaphore busyness uses register polling, whereas the engine

Re: [Intel-gfx] [PATCH v6 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.

Op 16-07-2020 om 00:42 schreef Manasi Navare: > From: Maarten Lankhorst > > Small changes to intel_dp_mode_valid(), allow listing modes that > can only be supported in the bigjoiner configuration, which is > not supported yet. > > eDP does not support bigjoiner, so do not expose bigjoiner only > m

Re: [Intel-gfx] [PATCH v6 03/11] drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split

This patch probably needs a description, typing somethign here since it was originally my patch: With bigjoiner, there will be 2 pipes driving 2 halfs of 1 transcoder, because of this, we need a pipe_mode for various calculations, including for example watermarks, plane clipping, etc. The transco

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/gt: Signal cancelled requests

== Series Details == Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests URL : https://patchwork.freedesktop.org/series/80459/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8862_full -> Patchwork_18329_full

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Correct the locking hierarchy in gem.

== Series Details == Series: drm/i915: Correct the locking hierarchy in gem. URL : https://patchwork.freedesktop.org/series/80465/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8862 -> Patchwork_18331 Summary --- **F

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Correct the locking hierarchy in gem.

== Series Details == Series: drm/i915: Correct the locking hierarchy in gem. URL : https://patchwork.freedesktop.org/series/80465/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Correct the locking hierarchy in gem.

== Series Details == Series: drm/i915: Correct the locking hierarchy in gem. URL : https://patchwork.freedesktop.org/series/80465/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3f559a19757d Revert "drm/i915/gem: Async GPU relocations only" -:121: WARNING:MEMORY_BARRIER: memory

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/vlv_dsi_pll: fix spelling mistake "Cant" -> "Can't"

== Series Details == Series: drm/i915/vlv_dsi_pll: fix spelling mistake "Cant" -> "Can't" URL : https://patchwork.freedesktop.org/series/80463/ State : success == Summary == CI Bug Log - changes from CI_DRM_8862 -> Patchwork_18330 Summary -

[Intel-gfx] [PATCH 19/24] drm/i915: Dirty hack to fix selftests locking inversion

Some i915 selftests still use i915_vma_lock() as inner lock, and intel_context_create_request() intel_timeline->mutex as outer lock. Fortunately for selftests this is not an issue, they should be fixed but we can move ahead and cleanify lockdep now. Signed-off-by: Maarten Lankhorst --- drivers/g

[Intel-gfx] [PATCH 06/24] drm/i915: Remove locking from i915_gem_object_prepare_read/write

Execbuffer submission will perform its own WW locking, and we cannot rely on the implicit lock there. This also makes it clear that the GVT code will get a lockdep splat when multiple batchbuffer shadows need to be performed in the same instance, fix that up. Signed-off-by: Maarten Lankhorst Rev

[Intel-gfx] [PATCH 14/24] drm/i915: Rework intel_context pinning to do everything outside of pin_mutex

Instead of doing everything inside of pin_mutex, we move all pinning outside. Because i915_active has its own reference counting and pinning is also having the same issues vs mutexes, we make sure everything is pinned first, so the pinning in i915_active only needs to bump refcounts. This allows us

[Intel-gfx] [PATCH 21/24] drm/i915: Use ww pinning for intel_context_create_request()

We want to get rid of intel_context_pin(), convert intel_context_create_request() first. :) Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/intel_context.c | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_context

[Intel-gfx] [PATCH 05/24] drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.

i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory eviction. We don't use it yet, but lets start adding the definition first. To use it, we have to pass a non-NULL ww to gem_object_lock, and don't unlock directly. It is done in i915_gem_ww_ctx_fini. Changes since v1: - Change ww_

[Intel-gfx] [PATCH 23/24] drm/i915: Add ww locking to vm_fault_gtt

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++- 1 file changed, 33 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c index b23368529a40..548ed9fb427d 100644

[Intel-gfx] [PATCH 08/24] drm/i915: Use per object locking in execbuf, v12.

Now that we changed execbuf submission slightly to allow us to do all pinning in one place, we can now simply add ww versions on top of struct_mutex. All we have to do is a separate path for -EDEADLK handling, which needs to unpin all gem bo's before dropping the lock, then starting over. This fin

[Intel-gfx] [PATCH 20/24] drm/i915/selftests: Fix locking inversion in lrc selftest.

This function does not use intel_context_create_request, so it has to use the same locking order as normal code. This is required to shut up lockdep in selftests. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 --- 1 file changed, 12 insertions(+), 3

[Intel-gfx] [PATCH 18/24] drm/i915: Convert i915_perf to ww locking as well

We have the ordering of timeline->mutex vs resv_lock wrong, convert the i915_pin_vma and intel_context_pin as well to future-proof this. We may need to do future changes to do this more transaction-like, and only get down to a single i915_gem_ww_ctx, but for now this should work. Signed-off-by: M

[Intel-gfx] [PATCH 10/24] drm/i915: Use ww locking in intel_renderstate.

We want to start using ww locking in intel_context_pin, for this we need to lock multiple objects, and the single i915_gem_object_lock is not enough. Convert to using ww-waiting, and make sure we always pin intel_context_state, even if we don't have a renderstate object. Signed-off-by: Maarten La

[Intel-gfx] [PATCH 01/24] Revert "drm/i915/gem: Async GPU relocations only"

This reverts commit 9e0f9464e2ab36b864359a59b0e9058fdef0ce47, and related commit 7ac2d2536dfa7 ("drm/i915/gem: Delete unused code"). Async GPU relocations are not the path forward, we want to remove GPU accelerated relocation support eventually when userspace is fixed to use VM_BIND, and this is t

[Intel-gfx] [PATCH 13/24] drm/i915: Pin engine before pinning all objects, v5.

We want to lock all gem objects, including the engine context objects, rework the throttling to ensure that we can do this. Now we only throttle once, but can take eb_pin_engine while acquiring objects. This means we will have to drop the lock to wait. If we don't have to throttle we can still take

[Intel-gfx] [PATCH 00/24] drm/i915: Correct the locking hierarchy in gem.

First start with a few reverts, to get to a good starting base for this series: - Async gpu relocations are not the way to go, for new platforms we will disable gpu relocations altogether. - We also need the relocation slowpath (EFAULT handling) back. - The eb_vma no longer needs to be refcounted

[Intel-gfx] [PATCH 16/24] drm/i915: Convert i915_gem_object/client_blt.c to use ww locking as well, v2.

This is the last part outside of selftests that still don't use the correct lock ordering of timeline->mutex vs resv_lock. With gem fixed, there are a few places that still get locking wrong: - gvt/scheduler.c - i915_perf.c - Most if not all selftests. Changes since v1: - Add intel_engine_pm_get/

[Intel-gfx] [PATCH 11/24] drm/i915: Add ww context handling to context_barrier_task

This is required if we want to pass a ww context in intel_context_pin and gen6_ppgtt_pin(). Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++- .../drm/i915/gem/selftests/i915_gem_context.c | 22 +++- 2 files changed, 48 insertions(+),

[Intel-gfx] [PATCH 09/24] drm/i915: make lockdep slightly happier about execbuf.

As soon as we install fences, we should stop allocating memory in order to prevent any potential deadlocks. This is required later on, when we start adding support for dma-fence annotations, and also required for userptr. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_ex

[Intel-gfx] [PATCH 22/24] drm/i915: Move i915_vma_lock in the selftests to avoid lock inversion, v3.

Make sure vma_lock is not used as inner lock when kernel context is used, and add ww handling where appropriate. Ensure that execbuf selftests keep passing by using ww handling. Changes since v2: - Fix i915_gem_context finally. Signed-off-by: Maarten Lankhorst --- .../i915/gem/selftests/i915_g

[Intel-gfx] [PATCH 07/24] drm/i915: Parse command buffer earlier in eb_relocate(slow)

We want to introduce backoff logic, but we need to lock the pool object as well for command parsing. Because of this, we will need backoff logic for the engine pool obj, move the batch validation up slightly to eb_lookup_vmas, and the actual command parsing in a separate function which can get call

[Intel-gfx] [PATCH 15/24] drm/i915: Make sure execbuffer always passes ww state to i915_vma_pin.

As a preparation step for full object locking and wait/wound handling during pin and object mapping, ensure that we always pass the ww context in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this happens. This also requires changing the order of eb_parse slightly, to ensure we pass

[Intel-gfx] [PATCH 02/24] drm/i915: Revert relocation chaining commits.

This reverts commit 964a9b0f611ee ("drm/i915/gem: Use chained reloc batches") and commit 0e97fbb080553 ("drm/i915/gem: Use a single chained reloc batches for a single execbuf"). When adding ww locking to execbuf, it's hard enough to deal with a single BO that is part of relocation execution. Chain

[Intel-gfx] [PATCH 03/24] Revert "drm/i915/gem: Drop relocation slowpath".

This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation slowpath"). We need the slowpath relocation for taking ww-mutex inside the page fault handler, and we will take this mutex when pinning all objects. With this, we have a proper working slowpath again, which will allow us to do fault

[Intel-gfx] [PATCH 04/24] Revert "drm/i915/gem: Split eb_vma into its own allocation"

This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974. With the WW locking, we will drop all references only at the end, so refcounting can be removed. Signed-off-by: Maarten Lankhorst --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 124 +++--- 1 file changed, 51 insertion

[Intel-gfx] [PATCH 24/24] drm/i915: Add ww locking to pin_to_display_plane

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 -- drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 + 2 files changed, 49 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i

[Intel-gfx] [PATCH 12/24] drm/i915: Nuke arguments to eb_pin_engine

Those arguments are already set as eb.file and eb.args, so kill off the extra arguments. This will allow us to move eb_pin_engine() to after we reserved all BO's. Signed-off-by: Maarten Lankhorst Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++

[Intel-gfx] [PATCH 17/24] drm/i915: Kill last user of intel_context_create_request outside of selftests

Instead of using intel_context_create_request(), use intel_context_pin() and i915_create_request directly. Now all those calls are gone outside of selftests. :) Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++--- 1 file changed, 29 insert

Re: [Intel-gfx] [PATCH] i915/gem: Force HW tracking to exit PSR

-Original Message- From: Chris Wilson Sent: Friday, August 7, 2020 5:30 PM To: Singh, Gaurav K ; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] i915/gem: Force HW tracking to exit PSR Quoting Gaurav K Singh (2020-08-07 12:56:33) > Instead of calling i915_gem_object_i

[Intel-gfx] [PATCH] drm/i915/vlv_dsi_pll: fix spelling mistake "Cant" -> "Can't"

From: Colin Ian King There is a spelling mistake in a drm_err message. Fix it. Signed-off-by: Colin Ian King --- drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_pll.c b/drivers/gpu/drm/i915/dis

Re: [Intel-gfx] [PATCH 00/37] Replace obj->mm.lock with reservation_ww_class

Quoting Tvrtko Ursulin (2020-08-06 10:21:38) > > On 05/08/2020 17:22, Thomas Hellström (Intel) wrote: > > Hi, Chris, > > > > > > On 8/5/20 2:21 PM, Chris Wilson wrote: > >> Long story short, we need to manage evictions using dma_resv & dma_fence > >> tracking. The backing storage will then be ma

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/gt: Signal cancelled requests

== Series Details == Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests URL : https://patchwork.freedesktop.org/series/80459/ State : success == Summary == CI Bug Log - changes from CI_DRM_8862 -> Patchwork_18329 Summ

Re: [Intel-gfx] [PATCH i-g-t v2 00/16] tests/core_hotunplug: Fixes and enhancements

On Fri, 2020-08-07 at 11:19 +0200, Janusz Krzysztofik wrote: > Clean up the test code and unblock unbind variants. From the CI report it looks for me like driver (hot)unbind-rebind operations affect hardware and the driver doesn't handle this correctly. Moreover, the test doesn't currently detect

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/gt: Signal cancelled requests

== Series Details == Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests URL : https://patchwork.freedesktop.org/series/80459/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH 2/3] drm/i915/selftests: Finish pending mock requests on cancellation.

Flush all the pending requests from the mock engine when they are cancelled. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/mock_engine.c | 29 +++ 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c b/drivers/gpu

  1   2   >