[Intel-gfx] [PATCH v3 1/1] drm/i915/xelpd: Enabling dithering after the CC1

If the panel is 12bpc then Dithering is not enabled in the Legacy dithering block , instead its Enabled after the C1 CC1 pipe post color space conversion.For a 6bpc pannel Dithering is enabled in Legacy block. Signed-off-by: Nischal Varide --- drivers/gpu/drm/i915/display/intel_color.c | 7 ++

[Intel-gfx] [PATCH v3 0/1] Enabling dithering after the CC1

v3 : Addressed Review Comments by (Bhanu) If the panel is 12bpc then Dithering is not enabled in the Legacy dithering block , instead its Enabled after the C1 CC1 pipe post color space conversion.For a 6bpc pannel Dithering is enabled in Legacy block. If the panel is 12bpc and display_ver < 13 th

[Intel-gfx] [PATCH v3 1/1] drm/i915/xelpd: Enabling dithering after the CC1

If the panel is 12bpc then Dithering is not enabled in the Legacy dithering block , instead its Enabled after the C1 CC1 pipe post color space conversion.For a 6bpc pannel Dithering is enabled in Legacy block. Signed-off-by: Nischal Varide --- drivers/gpu/drm/i915/display/intel_color.c | 7 ++

[Intel-gfx] [PATCH v3 0/1] Enabling dithering after the CC1

v3 : Addressed Review Comments by (Bhanu) If the panel is 12bpc then Dithering is not enabled in the Legacy dithering block , instead its Enabled after the C1 CC1 pipe post color space conversion.For a 6bpc pannel Dithering is enabled in Legacy block. If the panel is 12bpc and display_ver < 13 th

[Intel-gfx] [PATCH v2 9/9] drm/i915/gt: Setup a default migration context on the GT

From: Chris Wilson Set up a default migration context on the GT and use it from the selftests. Add a perf selftest and make sure we exercise LMEM if available. Signed-off-by: Chris Wilson Co-developed-by: Thomas Hellström Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gt/intel_gt.c

[Intel-gfx] [PATCH v2 7/9] drm/i915/gt: Pipelined page migration

From: Chris Wilson If we pipeline the PTE updates and then do the copy of those pages within a single unpreemptible command packet, we can submit the copies and leave them to be scheduled without having to synchronously wait under a global lock. In order to manage migration, we need to preallocat

[Intel-gfx] [PATCH v2 8/9] drm/i915/gt: Pipelined clear

From: Chris Wilson Update the PTE and emit a clear within a single unpreemptible packet such that we can schedule and pipeline clears. Signed-off-by: Chris Wilson Co-developed-by: Thomas Hellström Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gt/intel_migrate.c| 141 ++

[Intel-gfx] [PATCH v2 5/9] drm/i915/gt: Add a routine to iterate over the pagetables of a GTT

From: Chris Wilson In the next patch, we will want to look at the dma addresses of individual page tables, so add a routine to iterate over them. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 49 drivers/gpu/drm/i915/gt/intel_gtt.h | 7 ++

[Intel-gfx] [PATCH v2 6/9] drm/i915/gt: Export the pinned context constructor and destructor

From: Chris Wilson Allow internal clients to create and destroy a pinned context. Signed-off-by: Chris Wilson --- v2: - (Thomas) Export also the pinned context destructor --- drivers/gpu/drm/i915/gt/intel_engine.h| 11 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 27 ++

[Intel-gfx] [PATCH v2 4/9] drm/i915/gt: Add an insert_entry for gen8_ppgtt

From: Chris Wilson In the next patch, we will want to write a PTE for an explicit dma address, outside of the usual vma. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/gen8_pp

[Intel-gfx] [PATCH v2 3/9] drm/i915: Introduce a ww transaction helper

Introduce a for_i915_gem_ww(){} utility to help make the code around a ww transaction more readable. Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_ww.h | 31 +- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH v2 2/9] drm/i915: Break out dma_resv ww locking utilities to separate files

As we're about to add more ww-related functionality, break out the dma_resv ww locking utilities to their own files Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld --- v2: - Make sure filenames are sorted in include file lists and Makefile (Reported by Matthew Auld) --- drivers/gpu/

[Intel-gfx] [PATCH v2 1/9] drm/i915: Reference objects on the ww object list

Since the ww transaction endpoint easily end up far out-of-scope of the objects on the ww object list, particularly for contending lock objects, make sure we reference objects on the list so they don't disappear under us. This comes with a performance penalty so it's been debated whether this is r

[Intel-gfx] [PATCH v2 0/9] Prereqs for TTM accelerated migration

A couple of patches from Chris which implement pipelined migration and clears by atomically writing the PTEs in place before performing the actual blit. Some ww utilities mainly for the accompanying selftests added by Thomas, as well as modified the above patches for ww locking- and lmem support.

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/gem: ioctl clean-ups (rev6)

== Series Details == Series: drm/i915/gem: ioctl clean-ups (rev6) URL : https://patchwork.freedesktop.org/series/89443/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kernel: arch/x86/boot/bzImage i

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: ioctl clean-ups (rev6)

== Series Details == Series: drm/i915/gem: ioctl clean-ups (rev6) URL : https://patchwork.freedesktop.org/series/89443/ State : success == Summary == CI Bug Log - changes from CI_DRM_10194 -> Patchwork_20316 Summary --- **SUCCESS**

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: ioctl clean-ups (rev6)

== Series Details == Series: drm/i915/gem: ioctl clean-ups (rev6) URL : https://patchwork.freedesktop.org/series/89443/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/displ

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: ioctl clean-ups (rev6)

== Series Details == Series: drm/i915/gem: ioctl clean-ups (rev6) URL : https://patchwork.freedesktop.org/series/89443/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9bed855e16a0 drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE -:177: WARNING:FILE_PATH_CHANGES: added, moved or delete

[Intel-gfx] [PATCH 29/31] drm/i915/gem: Roll all of context creation together

Now that we have the whole engine set and VM at context creation time, we can just assign those fields instead of creating first and handling the VM and engines later. This lets us avoid creating useless VMs and engine sets and lets us get rid of the complex VM setting code. Signed-off-by: Jason

[Intel-gfx] [PATCH 31/31] drm/i915: Drop some RCU usage around context VMs

This instance now only happens during context creation so there's no way we can race with a context close/destroy. We don't need to bother with the RCU and can access the pointer directly. Signed-off-by: Jason Ekstrand --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 + 1 file c

[Intel-gfx] [PATCH 28/31] i915/gem/selftests: Assign the VM at context creation in igt_shared_ctx_exec

We want to delete __assign_ppgtt and, generally, stop setting the VM after context creation. This is the one place I could find in the selftests where we set a VM after the fact. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c

[Intel-gfx] [PATCH 30/31] drm/i915: Finalize contexts in GEM_CONTEXT_CREATE on version 13+

All the proto-context stuff for context creation exists to allow older userspace drivers to set VMs and engine sets via SET_CONTEXT_PARAM. Drivers need to update to use CONTEXT_CREATE_EXT_* for this going forward. Force the issue by blocking the old mechanism on any future hardware generations. S

[Intel-gfx] [PATCH 27/31] drm/i915/selftests: Take a VM in kernel_context()

This better models where we want to go with contexts in general where things like the VM and engine set are create parameters instead of being set after the fact. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- .../drm/i915/gem/selftests/i915_gem_context.c | 4 ++-- .../gpu/drm/i9

[Intel-gfx] [PATCH 21/31] drm/i915/gem: Use the proto-context to handle create parameters (v3)

This means that the proto-context needs to grow support for engine configuration information as well as setparam logic. Fortunately, we'll be deleting a lot of setparam logic on the primary context shortly so it will hopefully balance out. There's an extra bit of fun here when it comes to setting

[Intel-gfx] [PATCH 24/31] drm/i915/gem: Delay context creation (v2)

The current context uAPI allows for two methods of setting context parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The former is allowed to be called at any time while the later happens as part of GEM_CONTEXT_CREATE. Currently, everything settable via one is settable via the other.

[Intel-gfx] [PATCH 26/31] drm/i915/gem: Don't allow changing the engine set on running contexts (v2)

When the APIs were added to manage the engine set on a GEM context directly from userspace, the questionable choice was made to allow changing the engine set on a context at any time. This is horribly racy and there's absolutely no reason why any userspace would want to do this outside of trying t

[Intel-gfx] [PATCH 25/31] drm/i915/gem: Don't allow changing the VM on running contexts (v2)

When the APIs were added to manage VMs more directly from userspace, the questionable choice was made to allow changing out the VM on a context at any time. This is horribly racy and there's absolutely no reason why any userspace would want to do this outside of testing that exact race. By removin

[Intel-gfx] [PATCH 23/31] drm/i915/gt: Drop i915_address_space::file (v2)

There's a big comment saying how useful it is but no one is using this for anything anymore. It was added in 2bfa996e031b ("drm/i915: Store owning file on the i915_address_space") and used for debugfs at the time as well as telling the difference between the global GTT and a PPGTT. In f6e8aa38717

[Intel-gfx] [PATCH 22/31] drm/i915/gem: Return an error ptr from context_lookup

We're about to start doing lazy context creation which means contexts get created in i915_gem_context_lookup and we may start having more errors than -ENOENT. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++-- drivers/g

[Intel-gfx] [PATCH 20/31] drm/i915/gem: Make an alignment check more sensible

What we really want to check is that size of the engines array, i.e. args->size - sizeof(*user) is divisible by the element size, i.e. sizeof(*user->engines) because that's what's required for computing the array length right below the check. However, we're currently not doing this and instead doi

[Intel-gfx] [PATCH 19/31] drm/i915: Add an i915_gem_vm_lookup helper

This is the VM equivalent of i915_gem_context_lookup. It's only used once in this patch but future patches will need to duplicate this lookup code so it's better to have it in a helper. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c |

[Intel-gfx] [PATCH 18/31] drm/i915/gem: Optionally set SSEU in intel_context_set_gem

For now this is a no-op because everyone passes in a null SSEU but it lets us get some of the error handling and selftest refactoring plumbed through. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++ .../gpu/drm

[Intel-gfx] [PATCH 16/31] drm/i915/gem: Add an intermediate proto_context struct (v4)

The current context uAPI allows for two methods of setting context parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The former is allowed to be called at any time while the later happens as part of GEM_CONTEXT_CREATE. Currently, everything settable via one is settable via the other.

[Intel-gfx] [PATCH 17/31] drm/i915/gem: Rework error handling in default_engines

Since free_engines works for partially constructed engine sets, we can use the usual goto pattern. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/g

[Intel-gfx] [PATCH 15/31] drm/i915: Add gem/i915_gem_context.h to the docs

In order to prevent kernel doc warnings, also fill out docs for any missing fields and fix those that forgot the "@". Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- Documentation/gpu/i915.rst| 2 + .../gpu/drm/i915/gem/i915_gem_context_types.h | 43 +++

[Intel-gfx] [PATCH 13/31] drm/i915: Stop manually RCU banging in reset_stats_ioctl (v2)

As far as I can tell, the only real reason for this is to avoid taking a reference to the i915_gem_context. The cost of those two atomics probably pales in comparison to the cost of the ioctl itself so we're really not buying ourselves anything here. We're about to make context lookup a tiny bit

[Intel-gfx] [PATCH 14/31] drm/i915/gem: Add a separate validate_priority helper

With the proto-context stuff added later in this series, we end up having to duplicate set_priority. This lets us avoid duplicating the validation logic. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 + 1 file

[Intel-gfx] [PATCH 12/31] drm/i915/gem: Disallow creating contexts with too many engines

There's no sense in allowing userspace to create more engines than it can possibly access via execbuf. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu

[Intel-gfx] [PATCH 11/31] drm/i915/request: Remove the hook from await_execution

This was only ever used for FENCE_SUBMIT automatic engine selection which was removed in the previous commit. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +- drivers/gpu/drm/i915/i915_request.c | 42 --

[Intel-gfx] [PATCH 10/31] drm/i915/gem: Remove engine auto-magic with FENCE_SUBMIT (v2)

Even though FENCE_SUBMIT is only documented to wait until the request in the in-fence starts instead of waiting until it completes, it has a bit more magic than that. If FENCE_SUBMIT is used to submit something to a balanced engine, we would wait to assign engines until the primary request was rea

[Intel-gfx] [PATCH 09/31] drm/i915/gem: Disallow bonding of virtual engines (v3)

This adds a bunch of complexity which the media driver has never actually used. The media driver does technically bond a balanced engine to another engine but the balanced engine only has one engine in the sibling set. This doesn't actually result in a virtual engine. This functionality was orig

[Intel-gfx] [PATCH 08/31] drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES

This has never been used by any userspace except IGT and provides no real functionality beyond parroting back parameters userspace passed in as part of context creation or via setparam. If the context is in legacy mode (where you use I915_EXEC_RENDER and friends), it returns success with zero data

[Intel-gfx] [PATCH 07/31] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)

This API is entirely unnecessary and I'd love to get rid of it. If userspace wants a single timeline across multiple contexts, they can either use implicit synchronization or a syncobj, both of which existed at the time this feature landed. The justification given at the time was that it would he

[Intel-gfx] [PATCH 06/31] drm/i915: Drop the CONTEXT_CLONE API (v2)

This API allows one context to grab bits out of another context upon creation. It can be used as a short-cut for setparam(getparam()) for things like I915_CONTEXT_PARAM_VM. However, it's never been used by any real userspace. It's used by a few IGT tests and that's it. Since it doesn't add any

[Intel-gfx] [PATCH 04/31] drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem (v2)

Instead of handling it like a context param, unconditionally set it when intel_contexts are created. For years we've had the idea of a watchdog uAPI floating about. The aim was for media, so that they could set very tight deadlines for their transcodes jobs, so that if you have a corrupt bitstream

[Intel-gfx] [PATCH 05/31] drm/i915/gem: Return void from context_apply_all

None of the callbacks we use with it return an error code anymore; they all return 0 unconditionally. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++-- 1 file changed, 8 insertions(+), 18 deletions(-) diff --git

[Intel-gfx] [PATCH 03/31] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP

The idea behind this param is to support OpenCL drivers with relocations because OpenCL reserves 0x0 for NULL and, if we placed memory there, it would confuse CL kernels. It was originally sent out as part of a patch series including libdrm [1] and Beignet [2] support. However, the libdrm and Bei

[Intel-gfx] [PATCH 02/31] drm/i915: Stop storing the ring size in the ring pointer (v2)

Previously, we were storing the ring size in the ring pointer before it was actually allocated. We would then guard setting the ring size on checking for CONTEXT_ALLOC_BIT. This is error-prone at best and really only saves us a few bytes on something that already burns at least 4K. Instead, this

[Intel-gfx] [PATCH 01/31] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE

This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify ringsize on construction"). This API was originally added for OpenCL but the compute-runtime PR has sat open for a year without action so we can still pull it out if we want. I argue we should drop it for three reasons: 1.

[Intel-gfx] [PATCH 00/31] drm/i915/gem: ioctl clean-ups (v6)

Overview: - This patch series attempts to clean up some of the IOCTL mess we've created over the last few years. The most egregious bit being context mutability. In summary, this series: 1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP 2. Drops the entire CONTEXT_CLONE A

[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce i915_sched_engine object (rev3)

== Series Details == Series: Introduce i915_sched_engine object (rev3) URL : https://patchwork.freedesktop.org/series/90630/ State : success == Summary == CI Bug Log - changes from CI_DRM_10194_full -> Patchwork_20315_full Summary ---

Re: [Intel-gfx] [PATCH 02/13] drm/i915/guc: Update MMIO based communication

  #endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */ diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c index f147cb389a20..b773567cb080 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c @@ -376,29 +376,27 @@

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl_p: Add initial ADL_P Workarounds (rev2)

== Series Details == Series: drm/i915/adl_p: Add initial ADL_P Workarounds (rev2) URL : https://patchwork.freedesktop.org/series/91127/ State : success == Summary == CI Bug Log - changes from CI_DRM_10194_full -> Patchwork_20314_full Summar

[Intel-gfx] ✗ Fi.CI.BUILD: warning for Introduce i915_sched_engine object (rev3)

== Series Details == Series: Introduce i915_sched_engine object (rev3) URL : https://patchwork.freedesktop.org/series/90630/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kernel: arch/x86/boot/bzIm

[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce i915_sched_engine object (rev3)

== Series Details == Series: Introduce i915_sched_engine object (rev3) URL : https://patchwork.freedesktop.org/series/90630/ State : success == Summary == CI Bug Log - changes from CI_DRM_10194 -> Patchwork_20315 Summary --- **SUCCES

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Flush buffer pools on driver remove

== Series Details == Series: drm/i915: Flush buffer pools on driver remove URL : https://patchwork.freedesktop.org/series/91177/ State : success == Summary == CI Bug Log - changes from CI_DRM_10191_full -> Patchwork_20312_full Summary -

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/adl_p: Add initial ADL_P Workarounds (rev2)

== Series Details == Series: drm/i915/adl_p: Add initial ADL_P Workarounds (rev2) URL : https://patchwork.freedesktop.org/series/91127/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kernel: arch/x8

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl_p: Add initial ADL_P Workarounds (rev2)

== Series Details == Series: drm/i915/adl_p: Add initial ADL_P Workarounds (rev2) URL : https://patchwork.freedesktop.org/series/91127/ State : success == Summary == CI Bug Log - changes from CI_DRM_10194 -> Patchwork_20314 Summary ---

Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Pipelined page migration

On Tue, 2021-06-08 at 11:28 +0200, Thomas Hellström wrote: > From: Chris Wilson > > If we pipeline the PTE updates and then do the copy of those pages > within a single unpreemptible command packet, we can submit the > copies > and leave them to be scheduled without having to synchronously wait >

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/jsl: Add W/A 1409054076 for JSL (rev4)

== Series Details == Series: drm/i915/jsl: Add W/A 1409054076 for JSL (rev4) URL : https://patchwork.freedesktop.org/series/90129/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10191_full -> Patchwork_20311_full Summary ---

Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Pipelined page migration

On Tue, 2021-06-08 at 17:18 +0100, Matthew Auld wrote: > On Tue, 8 Jun 2021 at 10:29, Thomas Hellström > wrote: > > > > From: Chris Wilson > > > > If we pipeline the PTE updates and then do the copy of those pages > > within a single unpreemptible command packet, we can submit the > > copies >

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add "activ bpc" and "active color format" drm property

== Series Details == Series: Add "activ bpc" and "active color format" drm property URL : https://patchwork.freedesktop.org/series/91188/ State : failure == Summary == Applying: drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc Applying: drm/uAPI: Add "active bpc" as feedback

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Introduce a ww transaction helper

On Tue, 2021-06-08 at 18:17 +0100, Matthew Auld wrote: > On Tue, 8 Jun 2021 at 10:29, Thomas Hellström > wrote: > > > > Introduce a for_i915_gem_ww(){} utility to help make the code > > around a ww transaction more readable. > > > > Signed-off-by: Thomas Hellström > > --- > >  drivers/gpu/drm/i

[Intel-gfx] [PATCH 7/8] drm/i915: Update i915_scheduler to operate on i915_sched_engine

Rather passing around an intel_engine_cs in the scheduling code, pass around a i915_sched_engine. v3: (Jason Ekstrand) Add READ_ONCE around rq->engine in lock_sched_engine Signed-off-by: Matthew Brost Reviewed-by: Jason Ekstrand --- .../drm/i915/gt/intel_execlists_submission.c | 11 +++--

[Intel-gfx] [PATCH 8/8] drm/i915: Move submission tasklet to i915_sched_engine

The submission tasklet operates on i915_sched_engine, thus it is the correct place for it. v3: (Jason Ekstrand) Change sched_engine->engine to a void* private data pointer Add kernel doc Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/intel_engine.h| 14 --- drivers/gpu/dr

[Intel-gfx] [PATCH 6/8] drm/i915: Add kick_backend function to i915_sched_engine

Rather than touching execlist specific structures in the generic scheduling code, add a callback function in the backend. Signed-off-by: Matthew Brost --- .../drm/i915/gt/intel_execlists_submission.c | 52 drivers/gpu/drm/i915/i915_scheduler.c | 62 +--

[Intel-gfx] [PATCH 3/8] drm/i915: Reset sched_engine.no_priolist immediately after dequeue

Rather than touching schedule state in the generic PM code, reset the priolist allocation when empty in the submission code. Add a wrapper function to do this and update the backends to call it in the correct place. v3: (Jason Ekstrand) Update patch commit message with a better description Sig

[Intel-gfx] [PATCH 1/8] drm/i915: Move priolist to new i915_sched_engine object

Introduce i915_sched_engine object which is lower level data structure that i915_scheduler / generic code can operate on without touching execlist specific structures. This allows additional submission backends to be added without breaking the layering. This is a bit of detour to integrating the i

[Intel-gfx] [PATCH 0/8] Introduce i915_sched_engine object

As discussed in [1] we are breaking that large series into a several smaller ones. This series is stand alone patch part of step #4 which has no other dependencies or patches relevant to it. v2: (Daniel Vetter): - Split into several smaller patches - Add kernel doc for i915_sched_engine (Mat

[Intel-gfx] [PATCH 4/8] drm/i915: Move active tracking to i915_sched_engine

Move active request tracking and its lock to i915_sched_engine. This lock is also the submission lock so having it in the i915_sched_engine is the correct place. v3: (Jason Ekstrand) Add kernel doc Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/intel_engine.h| 2 - drivers

[Intel-gfx] [PATCH 5/8] drm/i915: Move engine->schedule to i915_sched_engine

The schedule function should be in the schedule object. v3: (Jason Ekstrand) Add kernel doc Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++-- drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 --- drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c

[Intel-gfx] [PATCH 2/8] drm/i915: Add i915_sched_engine_is_empty function

Add wrapper function around RB tree to determine if i915_sched_engine is empty. Signed-off-by: Matthew Brost Reviewed-by: Jason Ekstrand --- drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++--- drivers/gpu/drm/i915/gt/uc/i

[Intel-gfx] [PATCH v2] drm/i915/adl_p: Add initial ADL_P Workarounds

From: Clint Taylor Most of the context WA are already implemented. Adding adl_p platform tag to reflect so. v2: adjust comments for clarity (MattR) BSpec: 54369 Cc: Matt Roper Cc: Aditya Swarup Reviewed-by: Matt Roper Signed-off-by: Radhakrishna Sripada Signed-off-by: Anusha Srivatsa Signe

[Intel-gfx] [PATCH v2 7/7] drm/i915/display: Add handling for new "active color format" property

This commit implements the "active color format" drm property for the Intel GPU driver. Signed-off-by: Werner Sembach --- drivers/gpu/drm/i915/display/intel_display.c | 20 +++- drivers/gpu/drm/i915/display/intel_dp.c | 2 ++ drivers/gpu/drm/i915/display/intel_dp_mst.c |

[Intel-gfx] [PATCH v2 6/7] drm/amd/display: Add handling for new "active color format" property

This commit implements the "active color format" drm property for the AMD GPU driver. Signed-off-by: Werner Sembach --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 27 +-- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 + 2 files changed, 26 insertions(+), 2 deletions(-)

[Intel-gfx] [PATCH v2 2/7] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

Add a new general drm property "active bpc" which can be used by graphic drivers to report the applied bit depth per pixel back to userspace. While "max bpc" can be used to change the color depth, there was no way to check which one actually got used. While in theory the driver chooses the best/hi

[Intel-gfx] [PATCH v2 3/7] drm/amd/display: Add handling for new "active bpc" property

This commit implements the "active bpc" drm property for the AMD GPU driver. Signed-off-by: Werner Sembach --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c| 4 +++- 2 files changed, 20 insertions(+), 2 deletions(-) diff

[Intel-gfx] [PATCH v2 5/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

Add a new general drm property "active color format" which can be used by graphic drivers to report the used color format back to userspace. There was no way to check which color format got actually used on a given monitor. To surely predict this, one must know the exact capabilities of the monito

[Intel-gfx] [PATCH v2 1/7] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc

convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing. Signed-off-by: Werner Sembach --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 1 file changed, 4 insertions(+) diff --git a/dri

[Intel-gfx] [PATCH v2 4/7] drm/i915/display: Add handling for new "active bpc" property

This commits implements the "active bpc" drm property for the Intel GPU driver. Signed-off-by: Werner Sembach --- drivers/gpu/drm/i915/display/intel_display.c | 14 ++ drivers/gpu/drm/i915/display/intel_dp.c | 8 ++-- drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +++-

[Intel-gfx] [PATCH 0/7] Add "activ bpc" and "active color format" drm property

I started work on my proposal for better color handling in Linux display drivers: https://lkml.org/lkml/2021/5/12/764 In this 2nd revision the first two read-only properties are now implemented for amdgpu and i915. I post it here to collect collect some additional feedback, if someone sees an impr

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/2] drm/i915/display: Introduce new intel_psr_pause/resume function

On Tue, 2021-06-08 at 14:08 +, Patchwork wrote: Patch Details Series: series starting with [v4,1/2] drm/i915/display: Introduce new intel_psr_pause/resume function URL:https://patchwork.freedesktop.org/series/91152/ State: success Details: https://intel-gfx-ci.01.org/tree/drm-tip/

Re: [Intel-gfx] [PATCH 4/4] drm/i915/display: Add handling for new "active bpc" property

Am 07.06.21 um 22:33 schrieb Werner Sembach: Am 07.06.21 um 08:47 schrieb Werner Sembach: Am 04.06.21 um 19:30 schrieb Ville Syrjälä: On Fri, Jun 04, 2021 at 07:17:23PM +0200, Werner Sembach wrote: This commits implements the "active bpc" drm property for the Intel GPU driver. Signed-off-b

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Introduce a ww transaction helper

On Tue, 8 Jun 2021 at 10:29, Thomas Hellström wrote: > > Introduce a for_i915_gem_ww(){} utility to help make the code > around a ww transaction more readable. > > Signed-off-by: Thomas Hellström > --- > drivers/gpu/drm/i915/i915_gem_ww.h | 31 +- > 1 file changed, 30

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Break out dma_resv ww locking utilities to separate files

On Tue, 8 Jun 2021 at 10:29, Thomas Hellström wrote: > > As we're about to add more ww-related functionality, > break out the dma_resv ww locking utilities to their own files > > Signed-off-by: Thomas Hellström > --- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/ge

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Reference objects on the ww object list

On Tue, 8 Jun 2021 at 10:29, Thomas Hellström wrote: > > Since the ww transaction endpoint easily end up far out-of-scope of > the objects on the ww object list, particularly for contending lock > objects, make sure we reference objects on the list so they don't > disappear under us. > > This come

Re: [Intel-gfx] [PATCH V4] drm/i915/jsl: Add W/A 1409054076 for JSL

On Tue, Jun 8, 2021 at 6:38 AM Tejas Upadhyay wrote: > > When pipe A is disabled and MIPI DSI is enabled on pipe B, > the AMT KVMR feature will incorrectly see pipe A as enabled. > Set 0x42080 bit 23=1 before enabling DSI on pipe B and leave > it set while DSI is enabled on pipe B. No impact to se

Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Pipelined page migration

On Tue, 8 Jun 2021 at 10:29, Thomas Hellström wrote: > > From: Chris Wilson > > If we pipeline the PTE updates and then do the copy of those pages > within a single unpreemptible command packet, we can submit the copies > and leave them to be scheduled without having to synchronously wait > under

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Flush buffer pools on driver remove

== Series Details == Series: drm/i915: Flush buffer pools on driver remove URL : https://patchwork.freedesktop.org/series/91177/ State : success == Summary == CI Bug Log - changes from CI_DRM_10191 -> Patchwork_20312 Summary --- **SU

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915: Flush buffer pools on driver remove

== Series Details == Series: drm/i915: Flush buffer pools on driver remove URL : https://patchwork.freedesktop.org/series/91177/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kernel: arch/x86/boot/

[Intel-gfx] [PATCH] drm/i915: Flush buffer pools on driver remove

In preparation for clean driver release, attempts to drain work queues and release freed objects are taken at driver remove time. However, GT buffer pools are now not flushed before the driver release phase. Since unused objects may stay there for up to one second, some may survive until driver re

[Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915/jsl: Add W/A 1409054076 for JSL (rev4)

== Series Details == Series: drm/i915/jsl: Add W/A 1409054076 for JSL (rev4) URL : https://patchwork.freedesktop.org/series/90129/ State : warning == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh CHK include/generated/compile.h Kernel: arch/x86/boo

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/jsl: Add W/A 1409054076 for JSL (rev4)

== Series Details == Series: drm/i915/jsl: Add W/A 1409054076 for JSL (rev4) URL : https://patchwork.freedesktop.org/series/90129/ State : success == Summary == CI Bug Log - changes from CI_DRM_10191 -> Patchwork_20311 Summary --- **

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/2] drm/i915/display: Introduce new intel_psr_pause/resume function

== Series Details == Series: series starting with [v4,1/2] drm/i915/display: Introduce new intel_psr_pause/resume function URL : https://patchwork.freedesktop.org/series/91152/ State : success == Summary == CI Bug Log - changes from CI_DRM_10188_full -> Patchwork_20308_full ==

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add back the buddy allocator (rev3)

== Series Details == Series: Add back the buddy allocator (rev3) URL : https://patchwork.freedesktop.org/series/91110/ State : failure == Summary == Applying: drm/i915/ttm: add ttm_buddy_man Applying: drm/i915/ttm: add i915_sg_from_buddy_resource Applying: drm/i915/ttm: Calculate the object pl

[Intel-gfx] [PATCH 00/10] Allow mdev drivers to directly create the vfio_device

This is a "v3" of the previous posted full conversion: https://lore.kernel.org/r/0-v2-7667f42c9bad+935-vfio3_...@nvidia.com Without the trailing patches that are running into complications: - The CCW conversion has some complicated remarks - AP is waiting for some locking stuff to get worked o

Re: [Intel-gfx] [PATCH 00/10] Allow mdev drivers to directly create the vfio_device

Btw, you list of CCs is a mess as alsmost no one is CCed on the whole list can can thus properly review it. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/10] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE

Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 06/10] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE

For some reason the vfio_mdev shim mdev_driver has its own module and kconfig. As the next patch requires access to it from mdev.ko merge the two modules together and remove VFIO_MDEV_DEVICE. A later patch deletes this driver entirely. Signed-off-by: Jason Gunthorpe --- Documentation/s390/vfio-

[Intel-gfx] [PATCH V4] drm/i915/jsl: Add W/A 1409054076 for JSL

When pipe A is disabled and MIPI DSI is enabled on pipe B, the AMT KVMR feature will incorrectly see pipe A as enabled. Set 0x42080 bit 23=1 before enabling DSI on pipe B and leave it set while DSI is enabled on pipe B. No impact to setting it all the time. Changes since V3: - More meaning

  1   2   3   >